نوشته های معشوقه نرم افزار

نوشته های سعید فعله گری در مورد مباحث تخصصی نرم افزار، کتاب ، روانشناسی و رمان

تابوی نرم افزاری از نوع چشم آبی(تجربه کاری زیمنس)


نکته : تمامی این نوشته بر اساس تجربه شخصی شخص نویسنده اش نوشته شده است.پس ممکن است مانند نوشته های هر انسانی مملو از خطا و لبریز از اشکال باشد.

مقدمه :

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

حال تابو از نوع چشم آبی یعنی چه ؟

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

حال ممکن است با خود بپرسید که تابو یعنی چه ؟

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

تجربه :

این مقدمه را نوشتم تا به بیان تجربه کاری من برای زیمنس برسیم.

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

معمار نرم افزار آمریکایی بود.از نوع چشم آبی اش.

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

سیستم برای طراحی زیر ساخت های آینده وزارت بهداشت آلمان( به زبان فارسی) داشت طراحی میشد. سیستمی که قرار بود حداقل برای ده سال بدون هیچ نقصی کار کند.

بدون هیچ نقصی بتواند در هر ثانیه ، تعداد 3 میلیون Transaction  را بدون خطا و مکثی انجام دهد.

در چنین سیستمی به این عظمت، باید همه چیز ها را در تحلیل در نظر گرفت.

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

این کار تحلیلی من بر اساس دینامیک سیستم ها که سال 93 آن را شروع کرده بود ، هیچ ربطی به معمار نرم افزار نداشت و آن را برای دل خودم انجام دادم.

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

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

همین امتحان کردن باعث شد که برای دریافت جزئیات بیشتر، یک قرار را بگذارند و به تهران بیایند. اوایل سال 95 بود که به تهران آمدند.

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

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

من هم از پیش آموخته بودم که برای اینها باید با مدرک حرف بزنی. تمامی داشته هایم با همان لحن مغرور آلمانی گونه شان که با من حرف می زندند، ریختم روی دایره.

بعدش هم از کتابی که در عکس زیر مشاهده می کنید، مثال هایی را آوردم.


 


بر اساس تحلیل های  مالی – هزینه کپرس جونز(+)، دوباره برایشان تحلیل کردم. این بار لحنی که فکر می کردم دیگر هیچ چیزی برایم مهم نیست.

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

 در نهایت به آن ها گفتم که بروید و ادامه اش را خودتان بررسی کنید.

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

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

همه اینها را گفتم که این مسئله را بیان کنم :

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

 اگر می خواهید در این مورد بیشتر بخوانید ، بهتر است کتاب قضیه گودل(+) را مطالعه بفرمایید.

پا نوشت :

درست است که استاندارد است  و باید رعایت شود. اما اینهم درست نیست که فقط و فقط باید بر اساس نظر چشم آبی ها پیش برویم. این وسط کار خودمان چه می شود ؟

وجدان کاری چه می شود ؟ از این منظر که این سیستم ممکن است از نظر هزینه در آینده خیلی کمتر و بهتر شود.

 

ارسال نظر آزاد است، اما اگر قبلا در بیان ثبت نام کرده اید می توانید ابتدا وارد شوید.
شما میتوانید از این تگهای html استفاده کنید:
<b> یا <strong>، <em> یا <i>، <u>، <strike> یا <s>، <sup>، <sub>، <blockquote>، <code>، <pre>، <hr>، <br>، <p>، <a href="" title="">، <span style="">، <div align="">
تجدید کد امنیتی
Designed By Saeed Felegari استفاده از مطالب همراه با معرفی منبع آزاد است سعید فعله‌گری