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

پيشتر در هنگام توسعه سيستمهاي نرم افزاري با استفاده از روشهاي ساختيافته، مديران پروژه ها براي تخمين زمان و هزينه توليد يک سيستم قبل از آغاز آن از روشهاي مختلفي استفاده مي کردند.
از مهمترين  روشهاي تخمين  در آن زمان استفاده از تجربيات گذشته در سيستمهاي مشابه و يا تخمين تعداد خطوط برنامه و يا تعداد عملکردهاي متفاوت سيستم مي باشد.
بدين معني که يک برنامه ساز زماني که مي خواهد در آغاز پروژه زمان و هزينه لازم را برآورد کند براي مثال در يک جستجو در تجربيات خود  يک نمونه نزديک براي سيستم جديد پيدا مي کند. براي مثال در فلان سيستم دو ماه کار توسط يک گروه 2 نفره صورت گرفته است (به عبارتي 4 نفر-ماه) و چون پروژه جديد هم شبيه اين تجربه مي باشد همين حدود زمان براي توسعه سيستم نياز است و يا چون مثلا يک کم از آن بزرگتر است يک مقدار اضافه تر. گاهي هم بر اساس تخمين تعداد خطوط عمل مي شد. براي مثال برنامه ساز محاسبه مي کرد براي ايجاد سيستم نگارش حدودا 10.000 خط برنامه لازم است پس حجم پروژه معلوم است و بر اساس اينکه يک برنامه نويس در روز چند خط برنامه توليد مي کند (انگار کار برنامه نويسي پارچه بافي است که با يک معيار کمي آن را اندازه گيري مي کنيم!) کل زمان بدست بيايد. به همين شکل براي عملکرد ها هم عمل مي شد. و با شمارش تعداد عملکرد (Function)  هاي اصلي و فرعي سيستم حدود سيستم تخمين زده مي شد.
با توسعه روشهاي مهندسي نرم افزار و مطرح شدن مفاهيم شيء گرايي (Object Oriented Concept)  در مهندسي نرم افزار بالطبع معيارها و متريک ها نيز متفاوت شد. در شيء گرايي با تکيه بر استفاده مجدد يا بازکارآيندگي (Reuseability)   از يکسو فرآيند توليد نرم افزار سريعتر گرديد و از سوي ديگر معيارهايي نظير تعداد خطوط کارائي نداشت. چون ديگر در اينجا با نمونه سازي از اشياء و يا با استفاده از وراثت و يا چند ريختي نه تنها مي توان از يک کد نوشته شده در قالب يک شيء مي توان بارها استفاده کرد بلکه با گسترش يک کد در کلاسهاي ارث گرفته شده حجم کد نويسي مجدد را کاهش داد.
به همين منظور در روشهاي شيء گرايي با استفاده از شمارش تعداد کلاس هاي کليدي (Key Class) و کليد هاي کمکي يا پشتيبان (Support Class)  يک تخمين نسبت به حجم کلي سيستم بدست مي آيد.
در روشهاي ديگر با شمارش سناريو هاي کاري و يا شمارش زيرسيستمهاي سيستم هدف و با بهره گيري از تجربيات گذشته به يک روش نيمه فرمال براي تخمين زماني و مالي پروژه استفاده مي نمايند. اين روشها تخمين بهتري براي زمان و هزينه مالي پروژه به دست مي دهند.
نکته حائز اهميت اينکه هر چند اين روشها تخمين خوبي براي روشهاي شيء گرا هستند اما با مطرح شدن روشهاي جديد مهندسي نرم افزار از جمله روش توسعه نرم افزار مبتني بر مؤلفه ها (CBSD: Component Based Software Development) بايستي در اين معيار ها اصلاحاتي به وجود بيايد و تغييرات عمده اي صورت گيرد.
با استفاده از مؤلفه ها (Components) و چارچوب هاي (Frames)  مناسب براي يک پروژه مي توان زمان توليد نرم افزار را به طور چشمگيري کاهش داد. در نتيجه در تخمين زدن مي توان با توجه به مولفه ها و چارچوب هاي موجود در کتابخانه توليدي عمل کرد. هر چقدر اجزاء سيستم جديد با استفاده از ابزارهاي موجود  بيشتر قابل توسعه باشند مي توان پروژه را سريعتر توسعه داد.

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

همين!

همانگونه كه پيشتر در مطلبي در مورد مشاوره فنآوري اطلاعات نوشته بودم، يكي از مهمترين كارهاي مشاور قبل از آغاز يك پروژه تهيه RFP است. اين كار مشكلات خاص خود را دارد به طوري كه باعث مي شود برخي اوقات به يك كار طاقت فرسا و زمانگير تبديل شود. در بين مستندات مكتوب ابتدايي يك پروژه به نظر من پيچيده ترين است. شما در قرارداد (Contract) يك طرح به اندازه كافي مبهم نوشته مي شود كه بعدا بتوان روي آن مانور كرد!  در پيشنهاد (Proposal) هم   آنقدر بزرگنمايي و كلي گويي صورت مي گيرد كه يك طرح را بسيار بزرگتر از حد واقعي نشان داده و همه ابزارهاي مورد استفاده را بهترين ابزار معرفي كرد!

اما در RFP  طرح بايد به اندازه واقعي خود مشخص باشد و درخواست بايد به شكلي باشد كه پيشنهاد دهنده ها، پيشنهاد هاي نزديك به هم از نظر زمان و هزينه ارائه نمايند. در اينكار هم بايد نياز كارفرما در نظر گرفته شود و هم توانايي هاي شركتهاي مجري و فنآوري هاي موجود.
حال اگر اين RFP براي يك سازمان دولتي باشد كار مشكل تر هم مي شود چون بايد مقررات مختلف اداري را نيز در تهيه آن در نظر گرفت و تاييد بخش هاي مختلف را براي آن بدست آورد كه به دليل تنوع مقررات و كندي فرآيند كاغذ بازي هاي اداري و نيز تفاوت سليقه هاي مختلف كار مشكل تر هم مي شود.
به نظر مي رسد براي ارائه يك RFP  خوب بهتر است همانگونه كه در روشهاي تجزيه و تحليل سيستمها متدولوژي هاي استاندارد مطرح هستند و يا در برنامه سازي، زبانهاي برنامه نويسي بايد در تهيه اينگونه مستندات هم يك زبان فرمال وضع نمود.هر چند تلاشهاي در اين زمينه صورت گرفته است كه در اين بين مي توان به كار خوب "نماتن" اشاره كرد اما متاسفانه هم چيز در جهت قالب بندي و نگارش مستند به صورت سطحي باقيمانده است و تلاش جدي براي ارائه يك راه كار كلي تر و اصولي تر صورت نگرفته است. كاري كه در صورت انجام مي تواند حجم زيادي از فشارهاي كاري مشاورين فنآوري اطلاعات را كاهش دهد.

به لحاظ كاري هم اكنون مشاور يكي از شركتهاي دولتي بزرگ هستم در زمينه فنآوري اطلاعات و دولت الكترونيك و در اين مقطع از زمان در حال تهيه RFP مربوط به سيستمهاي اطلاع رساني شركت و به طور مشخص پايگاه اطلاع رساني اينترنتي و يا وب سايت شركت. در آغاز تهيه اين RFP فكر مي كردم كه اين گزارش در حداكثر دو هفته تا يك ماه اينكار جمع خواهد شد. كه همينگونه هم شد. در عرض 20 روز گزارش نهايي (از ديدگاه من) آماده شد و تحويل كارفرما شد اما از آن روز تا كنون (كه حدود 3 ماهي گذشته!) مدام در حال تغيير است و شايد جمع خطوط تغيير يافته اش روي هم به 10 خط هم نرسد! اما هر بخش از سازمان نظري مي دهد كه به نظر خودش بايد اعمال شود و اولويت ها را از ديدگاه خود تعيين ميكند و جمع كردن همه اين اولويت ها اغلب غير ممكن است و بايد به يك جمع بندي برسيم. فقط اميدوارم در هفته آينده اين RFP بالاخره تاييد شود تا بتوانم مرحله ديگري از كار را سريعتر آغاز كنم

همين!

یکی از استادان گرانقدرم در دوره کارشناسی، جناب آقای روحانی رانکوهی، همیشه از استادانی که دروس مختلفی را تدریس می کردند انتقاد می کردند و به آنها می گفتند: "فول چارت" : یعنی همه دروس چارت آموزشی را تدریس می کنند! همانطور که اسم عام دانشجو "تنبل" و اسم خاص من هم "دلار باز" بود! چون در زمان دانشجویی سر کار می رفتم و استاد این شیوه دانشجویی را نمی پسندیدند، بگذریم ....
انوقتها  با وجودیکه برای استاد احترام ویژه ای قائل بودم به نظرم این حرفشان درست نبود. فکر می کردم استاد "فول چارت" بودن نه تنها بد نیست بلکه این مساله که یک نفر دروس مختلف را در یک زمان تدریس کند نشانه تبحرش در همه دروس است و عمق دانش وی را نشان می دهد.

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

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

همین!

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

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

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

باز هم در این مورد مطلب خواهم نوشت ........

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

همین!

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

براي مثال در  پروژه آبتين ، حدود 70% از كار در مدت 2 هفته انجام شد. يعني براي يك پروژه به اين بزرگي از زمان دريافت سفارش تا آماده شدن نسخه اول 2 هفته بيشتر طول نكشيد كه زمان بسيار خوبي است. اما بعد از آن مواجه شديم با حجم زيادي از تغيير نيازها ، برخي از اين نيازها باعث شد كه بخشهايي از سيستم با تغييرات ساختاري مواجه شوند و حدود 2 ماه بعد درگير انجام اين تغييرات و در ادامه 30% انتهاي پروژه شديم.هر چند براي اين پروژه بيشتر فاز تحليل توسط نيروهاي داخلي سازمان كه بالطبع آشنايي خوبي با سيستم دارند صورت گرفته بود و مبناي كار پياده سازي بر اساس اين تحليل ها صورت مي گرفت ، تغييرات جديد مواردي بود كه نمي شد آنها را قبل از اتمام پروژه تشخيص داد. چون خود تحليل كنندگان هم با آن آشنا نبودند.

به جز اين بعد از تحويل نهايي نوبت نصب مي رسد كه فرآيند زمانگيري است(البته در ايران و به خصوص در مراكز دولتي). چون تا سيستمها آماده شوند و نيروهاي كاري آماده پذيرش سيستم جديد شوند معمولا روزهاي زيادي به بيهودگي مي گذرد.

اما در اين دو هفته گذشته به مرور  پروژه آبتين به مراحل  پاياني خود نزديك شد و تحويل گرديد. امروز هم بچه هاي شركت مشغول نصب دوباره نرم افزار بر روي سيستمهاي موجود مي باشند و به نظر مي رسد عامل ديگري موجب تاخير در اختتام پروژه نشود! مساله اي كه مي دانم تا زمان تاييد نهايي كتبي كارفرما نبايد زياد به آن دلخوش بود!

همين! 

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

در فرآیند ساخت سیستمهای اطلاعاتی مبتنی بر کامپیوتر (CBSD: Computer Based Information System) سه فرآیند اصلی نقش دارد: 1- فرآیند توسعه : شامل تمامی مراحل تجزیه و تحلیل، طراحی، پیاده سازی و تست سیستم و .... 2- فرآیند مدیریت : مدیریت پروژه نرم افزاری شامل همه اعمال تعریف ابزارها و تشکیل گروه کاری، زمانبندی و تخمین هزینه و .... 3- فرآیند پشتیبانی : شامل فعالیت های مرتبط با پشتیبانی و نگهداشت نرم افزار هر سه این فرآیند ها بایستی به دقت انجام شوند تا در نهایت یک پروژه نرم افزاری به نتیجه دلخواه خود برسد. اما متاسفانه در بازار نرم افزاری ایران اغلب شرکت های تولید کننده نرم افزار این مسائل را نادیده می گیرند و معمولا این فرآیند ها به خوبی پیموده نمی شود. با این وجود با توسعه متدولوژی های تجزیه و تحلیل سیستم ها و بالا رفتن سطح آگاهی مشتریان و بالطبع آن سطح توقعشان از یک نرم افزار ، گروه های تولید ناچار شده اند که فعالیت تجزیه و تحلیل سیستم ها را جزء مراحل ساخت سیستم خود در نظر بگیرند و زمان و هزینه آن از یک طرف و خروجی آن از طرف دیگر را جزء اجزای پروژه خود در نظر بگیرند.بگذریم از اینکه معمولا خروجی فازهای تحلیل و طراحی مورد استفاده در پیاده سازی قرار نمی گیرد! و معمولا فاز پیاده سازی همزمان با فاز تجزیه و تحلیل شروع می شود تا در زمانبندی سرعت ببخشند و گزارش های تحلیل و طراحی معمولا صرفا برای خالی نبودن عریضه و بستن دهان کارفرما تولید می شود. اما در فرآیند های دیگر همچنان ضعف به چشم می خورد. اکثر مدیران پروژه نرم افزاری در ایران، برنامه نویسان قدیمی تر و یا قوی تر گروه می باشند. در حالیکه فرآیند مدیریت دانش و توانایی خاص خود را می خواهد و بسیار متفاوت از برنامه سازی و یا حتی تجزیه و تحلیل سیستم هاست. هر چند یک مدیر پروژه باید در در جه اول برنامه نویس خوب و تحلیل گر خوبی باشد اما لزوما یک برنامه نویس خوب یک مدیر پروژه خوب نیست.به عنوان مثال مدیریت نیروی کارشناسی بحثی است که بسیار مشکل است و نیاز به تجربه و شناخت کافی از اخلاق و روحیات بدنه کارشناسی تولید کننده سیستم می باشد و یا از طرف دیگر بحث زمانبندی و تخمین های سیستم و یا مدیریت ریسک نیاز به دانش کافی از مسائل مرتبط دارد. فرآیند پشتیبانی که وضعیت بسیار بدتری نسبت به فرآیند های مرتبط با ساخت دارد. جو بی اعتمادی که در بین صنایع و شرکتها و سازمانهای ایرانی نسبت به تولید کنندگان نرم افزاری داخلی وجود دارد ناشی از همین ضعف است.برای نمونه چند ماه پیش در یک شرکت خصوصی متوسط (و نه بزرگ) جلسه داشتیم. این شرکت از بهترین (یا به عبارت بهتر معتبر ترین و یا باز هم دقیق تر فقط معروفترین!) شرکتهای تولید کننده سیستمهای جامع مالی ایران نرم افزار خریداری کرده بودند. ضعف در پشتیبانی از نرم افزارهای خریداری شده به حدی خریدار را دچار مشکل کرده بود که راه را در خرید نرم افزار از خارج از ایران و شرکتهای خارجی دنبال کرده بودند و با یک شرکت هندی در این زمینه قرارداد امضا کرده بودند! این که مشاهده می شود با وجودیکه در ایران اینهمه توانایی فنی نرم افزاری وجود دارد و اکثر شرکتهای نرم افزاری با مشکل پیدا کردن مشتری خوب مواجه هستند و در همینه حال خریداران با وجود گرانتر بودن قیمت از خارج نرم افزار تهیه می کنند واقعا تاسف برانگیز است. اما مقصر اصلی این مشکل خود شرکتهای نرم افزاری هستند چون فرآیند پشتیانی نرم افزار های خود را به خوبی انجام نمی دهند. در این باره باز خواهم نوشت. همین!

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

پيشتر در زمينه هايي مثل ساختمان سازي حضور يك نفر به عنوان مشاور در هنگاه تهيه طرح هاي مهندسي و همان فرد يا فرد ديگري به عنوان ناظر درهنگام اجراي پروژه به صورت يك امر عادي و لازم در آمده بود. بگذريم از اينكه در برخي موارد بحث مشاوره و يا نظارت به صورت يك مساله زينتي و صرفا براي رعايت مقررات در آمده است و ناظرين فقط زيربرگه ها را امضا مي كنند بدون اينكه نظارت به معناي واقعي داشته باشند و يا مشاورين با وجوديكه از طرف كارفرما مشغول به كار مي شوند به دليل در نظر گرفتن منافع خود نظر كارشناسي خوبي ارائه نمي دهند. چند سالي است بحث مشاوره و نظارت بر پروژه هاي نرم افزاري هم وارد بازار نرم افزاري ايران شده است. هر چند در سالهاي دور تر هم در برخي پروژه ها از وجود مشاور و يا ناظر استفاده مي شد اما امروز به دليل تنوع فعاليت ها و ابزار ها و گستردگي مطالب در صنعت نر افزار و يا به طور كلي در مباحث مرتبت با فنآوري ارتباطات و اطلاعات حضور فردي مطلع به عنوان مشاور كارفرما ضروري است. مشاور بايد با مطالعه سازمان و نيازمندي هاي آن طرحي در قالب يك RFP آماده كند . در اين گزارش ضمن پوشش نيازهاي سازمان بايستي فنآوري هاي روز و توانايي هاي فني موجود در شركت هاي مجري هم در نظر گرفته شود به نحوي كه نتيجه بتواند به عنوان مرجعي براي اجراي پروژه مورد نظر كارفرما قرارگيرد و پيمانكاران بتوانند با مطالعه آن ضمن اينكه به خوبي با مساله و محيط آن آشنا شوند بتوانند بر اساس موارد فني مطرح شده ابتدا متوجه شوند كه آيا قادر به انجام چنين پروژه اي مي باشند و پس از آن بتوانند تخمين نسبتا دقيقي در مورد هزينه هاي مالي و زمان اجراي پروژه داشته باشند. باز هم در اين مورد خواهم نوشت ...... يك نكته انحرافي بعد از تحرير! : سالها پيش زماني كه تازه وارد كار نرم افزار به صورت حرفه اي شده بودم فكر مي كردم مشاورين بيكارترين آدم هاي روي زمين هستند و برنامه نويسان ضمن اينكه پركارترين افراد هستند مهمترين كار روي زمين را هم دارند. امروز كه به عنوان مشاور برخي سازمانها مشغول به فعاليت هستم متوجه شده ام كه واقعيت چقدر با تصور چند سال پيش من متفاوت است. اينكه يك نفر در آن واحد بتواند هم نيازهاي كارفرما را برآورد كند و هم بتواند دانش كافي نسبت به فنآوري هاي روز داشته باشد و بتواند بين اين دو توازن برقرار كند كار بسيار دشواري است (امروز انقدر تجربه دارم كه نگويم دشوارترين كار روي زمين!) همين!

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

امروز جلسه ای در یک کارخانه صنعتی که در زمینه تولید لوازم خانگی فعالیت می کند بحث جدیدی در مورد کاربردهای گویا2 انجام دادیم.
این کارخانه یکی از بزرگترین تولید کنندگان نوع خاصی از لوازم خانگی است که تقریبا بازار ایران را به طور کامل پوشش داده است و به جز این صادرات خوبی به کشورهای خارجی داشته است.
مساله ای که هم اکنون فکر مدیران این کارخانه را به خود مشغول کرده است بحث خدمات پس از فروش و کیفیت ارائه این خدمات می باشد. نکته آنجاست که به دلیل حجم فروش بالا و بالطبع آن بالا بودن نرخ تماس ها برای پشتیانی فنی و ارائه خدمات پس از فروش کیفیت ارائه خدمات کاهش پیدا نکند. مشتریان بتوانند در 24 ساعت و در 7 روز هفته امکان برقراری تماس داشته باشند و این تماس ها به طور کامل ثبت گردد.
پیشنهاد ما به آنها -که خوشبختانه مورد قبول واقع شد!- آن بود که با کمک یک سیستم تلفن گویا اینکار را انجام دهند. به نحوی که در ساعات اداری سیستم به عنوان یک شروع کننده تماس مطرح باشد و به تماس گیرنده خوش آمد گوید تا زمانی که اپراتور سیستم را فعال نماید.
در ساعات غیر اداری سیستم خود فعال شده مشتری نوع دستگاه، اطلاعات تماس و شرح خرابی خود را با سیستم مطرح کند تا در ساعات اداری اپراتور با وی تماس برقرارکرده و تعمیر کار را به محل اعزام کند.
یکی دیگر از بخش های این سیستم سرویس دهی به نمایندگان خدمات پس از فروش شرکت در تمام کشور است . به طوریکه به صورت تمام وقت امکان ثبت سفارش قطعات یدکی و اعلام گزارش های مالی برای وی وجود داشته باشد.
به همان دلیلی که در مورد سیستم اطلاعات آموزشی در چند نوشته قبل مطرح شد فعلا نمی توانم اطلاعات دیگری در مورد این سیستم در وبلاگ مطرح کنم! بزودی -ظرف 3 هفته آینده سیستم تولید و آماده بهره برداری خواهد شد- اطلاعات مفصل در مورد این سیستم و مشتری فعلی آن و مشتریان بالقوه آن در قسمت گویا2 سایت رادمان مطلب خواهیم نوشت.
همین!

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