چرا تولید نرم‌افزار خیلی مشکل است؟

در این مقاله از سایت راکت، به این موضوع می‌پردازیم که چرا تولید نرم افزار کار مشکلی است؟

با ما همراه باشید تا ادامه این موضوع را برای شما شرح دهیم.

ما اغلب به تولید نرم‌افزار به عنوان یک حرفه با پایه منطق و علم فکر می‌کنیم. 

توسعه‌دهندگانی هستند که به‌صورت کلیشه‌ای و مانند یک عابد مذهبی به دنبال منطق و بیشتر از هم‌نوعانشان علاقه‌مند به اعداد باینری هستند. 

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

این سطح از آشفتگی چگونه ممکن است در یک نظم منطقی تحت نظارت دانشمندان باشد؟

اگر ما بتوانیم بهتر درک کنیم که پروژه‌ها چگونه در معرض شکست هستند، آن‌وقت یاد میگیریم که در آینده با پروژه‌ها با امنیت بیشتری رفتار کنیم. 

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

کلیشه‌هایی در مورد توسعه نرم‌افزار

تصّور ما از توسعه نرم‌افزار به‌عنوان یک حرفه منطق محور در این نمونه‌ها آورده شده است: دقت و قوانین دستوری زبان برنامه‌نویسی و برنامه‌هایی که به‌وسیله آنها نوشته می‌شوند. این موضوع، برداشت جمعی را به‌عنوان طرز فکر تکنیکی گسترش می‌دهد. 

قوانین بعضی از برنامه‌ها می‌توانند برای کاربران واضح باشند، بازی‌های ساده مثل مهاجمان فضایی معمولاً صفحه‌ای برای توضیح قوانین ندارند و از نظر ما ساده هستند. در سایر موارد احتمالاً این واضح است که یک برنامه قوانینی دارد اما اینکه چه قسمت‌هایی از آنها مُبهم است، باعث به وجود آمدن این پدیده آشنا می‌شود که: «کامپیوتر نه می‌گوید». 

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

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

ما بیشتر گرایش داریم که مهندسی نرم‌افزار را در قالب شکستنِ کدهای رمزدار تعریف کنیم تا کار آنها در زمینهٔ تولید نرم‌افزار. توسعه‌دهندگان نرم‌افزار همگی تحصیلات دانشگاهی ندارند و تمام وظایفشان در رابطه با مسائل به‌خوبی تعریف‌نشده است. 

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

پروژه‌ها می‌توانند به سمت‌وسوی اشتباهی بروند اگر مفروضات اشتباهی در رابطه با دنیای آنها داشته باشیم و یا اینکه ممکن است در مورد کاری که باید انجام دهند، گیج بشوند. 

حتی اگر چنین باشد، این تنها یک‌بخشی از توصیف روند ساخت آنهاست؛ چه چیزی باعث می‌شود که پروژه‌های نرم‌افزاری تا این حد خطرپذیر و در معرض شکست باشند؟ 

ما چگونه می‌توانیم به سمت نوشتن یک نرم‌افزار برویم؟

تصاویری از توسعه نرم‌افزار

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

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

اینکه بدانیم توسعه نرم‌افزار تا چه حد انتزاعی است، می‌تواند وسوسه‌ای باشد که برگردیم به سمت چیزهایی که مشابه قوانین سخت‌گیرانه هستند. مخصوصاً این وسوسه می‌تواند شبیه مهندسی فیزیک یا سازه باشد؛ بنابراین وسوسه درواقع تشابهی است که کاملاً تحت تأثیر روش‌های مدیریت پروژه نرم‌افزار است (بخصوص در مدل آبشاری)؛ اما باید مراقب موردی که در زیر آمده است باشیم:

Martin Fowler می‌گوید: «من خیلی نسبت به استفاده از سمبل دیگر تخصص‌ها برای گرفتن نتیجه در مورد توسعه نرم‌افزار مشکوک هستم. به‌طورخاص، من عقیده دارم که سمبل مهندسی به تخصص ما آسیب‌زده است درجایی که تشویق به مسئله جداسازی طرح از سازه کرده است.»

همان‌طور که Fowler اشاره کرد، این خطرناک است که ما فکر کنیم به‌صورت تخصصی می‌دانیم که مشکلات چه هستند.

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

برنامه‌نویسان فقط کدی نمی‌نویسند که مسائل را حل کند، آنها کدهای زیادی می‌نویسند که راه‌حل‌های دیگران را به هم ارتباط می‌دهند. 

بسته به انتخاب‌های مختلف، ساخت یک ابزار کاری ممکن است برای یک هدف خاص، سخت باشد (نیاز به مقدار زیادی فکر و ابزارهای ارتباطی داشته باشد) یا یک کار روتین و یا اینکه ممکن است از نظر اجرایی یک کار غیرممکن باشد.

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

مفروضات اولیه غیرقابل بحث در مورد ابزارها می‌توانند منجر به پیشی گرفتن از ملزومات و یا افزایش هزینه‌ها بشوند که درنهایت به روند شکست کمک می‌کند. 

بیشتر افکار آسیب‌زا، تمایل به مفروضات اولیه غیرقابل بحث در فضای اهداف تجاری دارند. در اینجا بازهم سمبل ساختار نمی‌تواند خطرات را بازتاب دهد. 

یک دامنه قطعی برای مفروضات اشتباه وجود دارد که منجر به بروز خطا در موارد زیر می‌شود: 

آیا یک طراحی سازه می‌تواند فضای کافی برای استفاده‌کنندگان از آن فراهم کند؟ 

آیا آسانسور به‌ اندازه کافی در نظر گرفته‌ شده است؟

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

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

یک سمبل بهتر

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

همان‌طور که داستان پیش می‌رود، مردان Rangar به او خبر می‌دهند که یک زن بسیار زیبا به نام Kraka را دیده‌اند. اشتیاق و علاقه پادشاه بیدار می‌شود و آن را با Kraka در میان می‌گذارد؛ اما تصمیم می‌گیرد که هوش او را بیازماید. 

به او دستور می‌دهد که طوری به قصر پادشاه بیاید که نه پوشیده باشد و نه عریان، نه سیر باشد و نه گرسنه، نه گروهی او را همراهی کنند و نه‌تنها بیاید. Kraka به این صورت از پس این چالش برآمد که لباسی از جنس تور پوشید و درحالی‌که یک پیاز را گاز میزد و سگش او را همراهی می‌کرد، داخل شد. Rangar تحت تأثیر قرار گرفت و با او ازدواج کرد. 

درخواست‌های Rangar در حداقل یک ویژگی کلیدی بی‌شباهت به مشخصه‌های یک پروژه نرم‌افزاری نیستند. Rangar کاملاً نمی‌دانست که درخواست‌هایش چگونه قرار است برآورده شوند تا زمانی که Kraka را دید. او می‌دانست که شروطش قطعاً باید برآورده شوند اما هیچ ایدهای در مورد راه‌حل‌هایی که قرار بود Kraka پیدا کند، نداشت تا زمانی که او را دید. 

برای دیدن این ارتباط با وضوح بیشتر، بیایید تصور کنیم که Rangar فوراً با Kraka ازدواج نکرد و در عوض درخواست بعدی‌اش را مطرح کرد، مبنی بر اینکه او باید خودش را در یک تمرین سختتر هم اثبات کند و از او خواست که سیستمی تولید کند که مستندات مربوط به پذیرش یا مردودیت را پردازش کند و یک تیم کامل هم در اختیار او قرار می‌دهد. 

در مورد مشخصه‌ها Rangar درک کمی از چگونگی انجام این وظایف بدون نیاز به یک تیم دارد. او چیزی بیشتر از معمای اولش در مورد امکان‌پذیری پردازش مستندات پذیرش و مردودیت بدون یک تیم، نمی‌داند. 

او نیاز دارد که راه‌حل را بداند قبل از اینکه بتواند بداند که آیا آن راه‌حل آنچه را که او مستندسازی پذیرش و مردودیت می‌خواند، پوشش می‌دهد یا نه.

این مهم است که در هر دو مورد، Kraka ناچار است او را به یک قلمرو ناشناخته ببرد. Rangar مطمئناً نمی‌داند که چه چیزهایی را پوشیده و نپوشیده می‌داند. مشابهاً او نمی‌داند که چه چیزهایی را مستندات پذیرش و یا مردودیت می‌نامد بدون داشتن یک تیم که پذیرش یا مردودیت را اجرا کنند و Kraka باید بفهمد که با چه راه‌حلی می‌تواند از پس این چالش بربیاید. 

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

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

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

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

بیایید به مثال Rangar و Kraka برگردیم و تصور کنیم که Kraka بجای یک سگ با یک خرگوش می‌آمد؛ Rangar ممکن است که بگوید این راه‌حل را قبول ندارد و خرگوش به‌هیچ‌عنوان یک همراه به‌حساب نمی‌آید. 

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

Kraka ممکن است از قبل از شروع، دنبال چنین مسئله‌ای بوده باشد. او ممکن بود یک تحلیل از ملزومات انجام داده باشد. ما می‌توانیم تصور کنیم که Kraka از یک تحلیل‌گر تجاری کمک خواسته است و سؤالاتی از این قبیل از او پرسیده باشد: 

آیا منظور از همراه، تنها همراه انسان است؟ یک حیوان خانگی چطور؟

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

موارد استفاده از سمبل‌ها

من شخصاً یک سمبل حل مسئله منطقی پیدا کردم در زمان بازگشت به مسئله وقتی‌که وسوسه شدم به دنبال یک پاسخ قطعی بگردم برای اینکه آیا یک طراحی خاص کار خواهد کرد یا یک ابزار منتخب با نیاز خاص منطبق خواهد شد یا نه. 

گاهی ما نمی‌توانیم مطمئن شویم که یک راحل تخصصی جواب می‌دهد یا نه. احتمالاً ما خیلی به دنبال آن عدم قطعیت صریح هستیم، اما نمی‌توانیم به آن دست پیدا کنیم. 

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

فکر کردن به پروژه از طریق مقایسه‌های "open-ended" از مسائل منطقی که حل می‌شوند، به من کمک می‌کند که اهمیت جنبه‌هایی را ببینم که ممکن است تا آن زمان به آنها مشرف نبوده باشم. 

این بیشتر از دیدن مجموعه‌ای از نمودارهای "burn-down" می‌تواند منطقی را برای من به وجود بیاورد که پویایی پروژه را بهتر درک کنم. 

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

سخن پایانی

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

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

در زیر تجارب خود مبنی بر مشکلاتی که در هنگام تولید نرم‌افزار داشته‌اید با ما به اشتراک بگذارید. 

منبع