وب سایت شخصی حمیدرضا متقیان

بی شک برای استفاده از هر روش جدیدی دلایلی وجود دارد.  یکی از این دلایل می تواند برتری نقاط قوت روش جدید نسبت به روش فعلی باشد. اما آیا همیشه اینطور است؟ اگر شما به یکی از دلایل ذیل می خواهید به اجایل مهاجرت کنید باید بدانید که دچار افسانه زدگی Agile شده اید! این موارد افسانه های Agile هستند:

• Agile development does little planning
• Agile development does little analysis
• Agile developers don’t write documentation
• Agile development “squeezes” roles out of the organization
• Agile development can’t provide accurate project schedules to support organizational planning

این نکته رو همواره به یاد داشته باشیم که در Agile همیشه همه موارد به میزان کافی هستند نه بیشتر و نه کمتر.

این مقاله در وبلاگ Jeff Sutherland در سال ۲۰۰۲ به نقل از لارمن کریج نوشته شده که خوندنش خالی از لطف نیست. این پست در تکمیل پست قبلیم هست تا بعضی از دوستان بدونن که تا چه حد RUP رو اشتباه فهمیدن و اشتباه اجرا میکنن.

اگر شما هم مثل ۱۱ مورد زیر در مورد RUP فکر می کنید حتماً باید آگاهیتون رو درباره RUP بیشتر کنید:

• وقتی فکر می کنیم  inception=requirements و elaboration=design و construction=implementation
• وقتی فکر می کنیم هدف از elaboration اینه که مدل ها باید بصورت کامل و با دقت تعریف بشن و لزوماً فقط همین مدل ها هستن که در فاز construction تبدیل به کد خواهند شد.
• وقتی فکر می کنیم در فاز elaboration فقط پروتوتایپ ها باید ساخته بشن. در واقع هسته کیفی المان های مهم معماری باید در این فاز تبیین بشن.
• وقتی سعی می کنیم اغلب نیازمندی ها قبل از شروع مرحله طراحی یا پیاده سازی تعریف بشن.
• وقتی سعی می کنیم اغلب امور مربوط به طراحی رو قبل از شروع پیاده سازی تمام کنیم.
• وقتی قبل از شروع کدنویسی زمان زیادی رو صرف تکمیل نیازمندی ها و امور طراحی می کنیم.
• وقتی فکر می کنیم مدت مناسب هر iteration یا تکرار باید بر حسب ماه باشه نه بر حسب هفته.
• وقتی فکر می کنیم در مرحله رسم نمودارهای UML و انجام فعالیت های مربوط به طراحی، زمان زیادی باید صرف شه تا حتماً پیش نویس کدها به درستی و بصورت کامل آماده شه تا در مرحله کدنویسی این خروجی ها به سادگی به کدهای اصلی تبدیل شن.
• وقتی سعی می کنیم در ابتدای کار، کل پروژه رو از آغاز تا پایان برنامه ریزی کنیم بطوریکه جزئیات و رویدادهای هر تکرار از همون ابتدا پیش بینی بشه.
• وقتی سازمان از شما میخواد قبل از ورود به فاز elaboration، برنامه قابل قبول و پیش بینی های اصلی پروژه رو آماده کنید.
• وقتی سازمان شما فکر میکنه پذیرفتن RUP به این معنی هست که خیلی از فعالیت های اختیاری رو باید بطور کامل انجام بدیم و در هر مرحله باید داکیومنت کاملی رو تولید کنیم و همچنین فکر میکنه تجربه موفق در RUP مثل یک فرآیند معمولی میمونه که لزوماً با گذروندن خیلی از مراحل از پیش تعیین شده محقق میشه.

موفق باشید.

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

پیچیده بودن فرآیند تولید و توسعه نرم افزار باعث خلق متدولوژی ها و روش های متفاوتی شده. بالاخره برای مدیریت یک فرآینده پیچیده و فوق العاده پارامتریک و در عین حال پویا باید روش داشت! از روز اول خیلی از روش ها بکار گرفته شد و به مرور زمان ایراداتش گرفته شد و روش دیگه ای جایگزین شد. این خیلی هم خوبه! بالاخره پیشرفت یعنی همین. متدولوژی های توسعه نرم افزار تقریباً از دهه ۷۰ تازه آغاز شد. با Structured Programming  شروع شد و در سال ۱۹۸۰ رسید به SSADM. در دهه ۹۰ اتفاقات خوبی افتاد. OOP، RAD، Scrum و در پایان سال ۹۰ رسیدیم به XP و در اواخر همین دهه RUP و در اوایل دهه بعدی Agile معرفی شد و در سال ۲۰۰۵ اِی.یو.پی به یونیفاید پروسس ها اضافه شد. ذکر این نکته شاید برای شما هم جالب باشه که اوج تحول اسکرام مربوط به سال ۹۵ میشه سالی که هنوز UP شکل آنچنانی ای نگرفته بود البته مسلماً اون اسکرام با این اسکرام هم متفاوته. RUP هم که در سال ۹۶ تازه شکل گرفته بود در سال ۹۸ جون گرفت و در سال ۲۰۰۳ با توجه به حمایت IBM رسماً معروف شد. این در حالیه که Agile رسماً در سال ۲۰۰۱ معرفی شد و اسکرام بعنوان یک روش بکارگیری Agile به اجایل پیوست. البته این رو هم باید در نظر داشت که Incremental software development methods که سازگار با اجایل  هستن در سال های قبل به تدریج در حال تکمیل بودن. متدهای اسکرام، اکس پی و کریستال مربوط به قبل از سال ۹۶ هستن و در واقع تفکر اجایل قبل از ۲۰۰۱ هم وجود داشت همونطور که تفکر UP هم قبل از ۲۰۰۳ بود. تا اینجا ذکر این نکته مهم هست که اجایل چیز جدید و تازه ای نیست چراکه نزدیک ۱۰ سال از معرفی رسمی اون میگذره. اما چیزی که هست اینه که فراگیر شدن اسکرام و کلاً تفکر اجایل اخیراً اتفاق افتاده…

متاسفانه در بعضی از انجمن ها و جدیداً در برخی از شرکت ها ذهنیت غلطی دیدم امیدوارم تا حدی بتونم اصلاحش کنم. اون ذهنیت چیه؟ بذارید یه مقدمه اول بگم. عموماً تغییر چیز خوبیه مخصوصاً اگه این تغییر همگام با پیشرفت تکنولوژی باشه و ایرادات قبلی رو اصلاح کرده باشه. اما باور تغییر و باور علت تغییر خیلی مهم تر هست. من اگه فقط در ظاهر تغییر کنم بدون اینکه علت رو بدونم و باور نداشته باشم که این تغییر باعث موفقیت من میشه واقعاً بی فایده هست. بالاخره اکثر دانشجویان کامپیوتر در ایران در درس مهندسی نرم افزار با آر.یو.پی آشنا شدن. حالا اینکه چرا اون موقع کسی بجای آر.یو.پی، اجایل رو معرفی نکرد مشخص نیست! ممکنه بعضی از دوستان بگن اون موقع اجایل شناخته شده نبود یا عملیاتی نبود یا … به نظر من این دلایل قابل قبول نیست. البته شاید در بعضی از دانشگاه ها اینطور نبوده باشه ولی تا اونجایی که من از دوستان و آشنایان پرسیدم بالای ۹۰ درصد اینجوری بوده و مهندسین آینده هیچ چی در مورد اجایل نشنیدن. خوب بگذریم… پس به دلایل نامشخصی RUP بعنوان یک فریم ورک اصلی توسعه نرم افزار شناخته شد معرفی و عملیاتی شد. در خیلی از پروژه ها مورد استفاده قرار گرفت. پروژه های موفق داشت ناموفق هم داشت. اون چیزی که زنگ خطر بحساب میاد اینه که متاسفانه این تفکر داره ترویج میشه که دلیل عدم موفقیت برخی پروژه های نرم افزاری ای که از RUP استفاده کردن خودِ RUP هست و برای اینکه موفق بشیم باید متدولوژی رو عوض کنیم و مثلا اسکرام کار کنیم! شاید در برخی از پروژه ها این حرف صحیح باشه ولی عموماً اینطور نیست. این یک باور غلط هست مواظب باشید گرفتارش نشین. RUP یک فریم ورک گسترده هست و اون چیزی که باید در RUP بدرستی رعایت شه tailoring هست. کسی که این وظیفه رو بعهده میگیره باید علاوه بر تخصص، تجربه بالایی داشته باشه. عموماً پروژه هایی که موفق نمیشن در Tailoring مشکل دارن. این مساله به ضعف RUP برنمیگرده. متاسفانه هیچ مرجع کاملی برای آموزش RUP در کشور وجود نداره. خیلی از افرادی که RUP کار میکنن حتی نسخه جدید ۲۰۰۸ اون رو ندیدن!! یا شیوه پیاده سازیشون اصلاً از پایه غلط هست. من در مورد مزایا و معایب RUP نمیخوام صحبت کنم هدفم این هست که بگم شرایطی که RUP الان داره رو ما خودمون بوجود اوردیم نه کس دیگه و باید مواظب باشیم که این شرایط رو برای Agile و Scrum بوجود نیاریم به این معنی که قبل از عالم شدن شروع کنیم. البته این رو هم قبول داریم که این اتفاق احتمال وقوع کمتری در اجایل داره ولی باز مهم هست و قابل وقوع٫

خیلی از افرادی که ادعای RUP دارن واقعاً علم به حداقل ها رو هم ندارن و اصلا iteration ای ندارن و کاملاً دارن به سبک SSADM کار میکنن. این افراد جایگاه RUP رو با نادانی شون خراب کردن. این تفکر مسلماً به شکست خواهد انجامید چراکه باور این افراد درست نیست. علم به روش از خودِ روش مهمتر هست. وقتی من علم به ابزار رو ندارم چطور میتونم از ابزار استفاده کنم. مسلماً از یک روش در همه پروژه ها نمیشه استفاده کرد. ولی اگر در پروژه ای موفق نشدیم اول اینو بررسی کنیم که آیا روش رو درست انتخاب کردیم بعد ببینیم آیا علم به اون روش رو داشتیم و در آخر خودِ روش رو زیر سوال ببریم و دنبال توجیه بی دانشی خودمون باشیم.

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

موفق باشید.

یادمه روزی روزگاری همگان از رویت اِی جکس متحیر شده بودن از جمله خودم! مسلماً ِای جکس نقطه عطفی در نمودار تاریخچه وب بشمار میاد. اما حالا سوالم اینه که از این نقطه عطف ها باز هم هست یا نه؟ به نظر من نقطه عطف دیگه نسخه پنجم HTML هست که تحول زیادی در دنیای وب ایجاد خواهد کرد. البته مستعد ایجاد تحول هست ولی رویداد این تحول کمی پیچیده و شاید زمانبر باشه. حتی اگر نصف این تحول هم محقق بشه در نوع خودش بی نظیر خواهد بود. کلا من از تحول های اینجوری خوشم میاد. البته واضحه که وقوع هر تحولی نیازمند تغییر خیلی از پارامترها و آماده شدن بسترهای لازم برای تغییر هست. شاید کنار اومدن با این موضوع کمی سخت باشه ولی لازم الاجرا و در آخر جذابه. یه تغییرِ ساده مرورگره. من نمیتونم با IE6 از وب سایت هایی که از HTML5 استفاده کردن بازدید کنم. پس لازمه ی هر تغییری در دنیای کامپیوتر بروزرسانی ابزاره که همه میدونیم. این تغییر برای مخاطب باید اتفاق بیفته. اما باعث این تغییر کی شده؟ پاسخ: طراح وب. این طراح وب بوده که در طراحیش از HTML5 استفاده کرده و مخاطب رو مجبور به آپدیت مرورگر کرده. طراحان وب بدون کسب دانش جدید که نمیتونن از تکنولوژی های جدید در کارهاشون استفاده کنن. پس اون روی سکه بروزرسانی دانش تولیدکننده هاست که جزء لاینفک و مهم زندگی هر مهندس کامپیوتری هست. اگر هنوز یادگیری HTML5 رو شروع نکردید همین امروز اقدام کنید.

اما برسیم سر اصل مطلب. HTML5 چیکار کرده که بهش میگم تحول؟! همونطور که میدونید در دنیای وب افکت های صوتی و تصویری باعث جذاب تر شدن وب سایت ها میشن البته در حد استانداردش. برای بکارگیری این جلوه ها Flash بعنوان یک ابزار به وب ورود کرد. اما ازونجائی که آدمی در هر چیزی افراط و تفریط میکنه ییهو وب سایت های فول فلش خلق شد و عوام سایت های غیر فلش رو سایت نمیدونستن و فکر میکردن در هر سایتی که فلش بکار گرفته نشه از لحاظ طراحی ضعیف بحساب میاد! البته در اون روی سکه هم در هنگام استخدام طراح وب یکی از توانمندیها صددرصد دانش Flash بود!( شکر خدا این موارد تا حدودی بهبود پیدا کردن) خلاصه اینکه خلا نبود مالتی مدیا در وب احساس می شد که این خلا توسط Flash پر شد. اما بعد از مدتی فریم ورک های جاوااسکریپت تولید شدن که معروفترینشون jQuery بود. جاوااسکریپت قدرت فوق العاده ای در خلق انیمیشن پیدا کرد و کمک زیادی به افزایش کیفیت گرافیک در وب کرد. شاید با وجود jQuery و افکت ها و متدهای آماده اون در زمینه انیمیشن به تدریج از لزوم استفاده از انیمیشن های Flash ای کاسته شد و بدلیل سازگاری بهتر جاوااسکریپت با موتورهای جستجوگر و ضعف Flash در مفاهیم SEO رفته رفته موارد استفاده Flash در وب کمتر و کمتر شد. اما HTML5 این داستان رو تکمیل کرد و با معرفی المان های جدیدی مانند audio، video یا canvas قابلیت های ذاتی HTML و جاوااسکرپیت رو تا حدی تقویت کرد که وب رو بی نیاز از Flash کرد. البته ذکر این نکته مهم هست که هدف HTML5 لزوماً حذف Flash از دنیای وب نیست ولی در کل قابلیت Animate شدن و ویژوال تر شدن وب بدون استفاده از ابزار جانبی مهمترین کاربرد HTML5 در آینده خواهد بود. اما جدای از این ویژگی HTML5 قابلیت های دیگه ای از ترکیب HTML و جاوااسکریپت بوجود اومد که ساده ترینشون input email  هست. مسلماً با مفاهیم Regular Expression آشنا هستید… واقعاً آدم لذت میبره از این همه ساده تر شدن کارها و روش ها. اما قدرت و تحول HTML5 به اینجا هم ختم نمیشه! در پست های بعدی سعی میکنم مهمترین قابلیت های HTML5 رو بطور خلاصه بررسی کنم.

منتظر خلق دنیای وب جدیدی از ترکیب HTML5 و CSS3 باشید.

مرا بسپار در یادت
به وقت بارش باران…
نگاهت گر به آن بالاست
و در حال دعا هستی
خدا آنجاست… دعایم کن…
دعایم کن که من محتاج محتاجم…

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

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

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

موفق باشید.

یاد GODISNOWHERE افتادم که هم میشه GOD IS NOW HERE خوندش هم GOD IS NO WHERE!

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

از نظر فنی اگر تیمی بتونه یه CMS ایده آل و کارا تولید کنه باید به اون تیم تبریک گفت چون تولید CMS یک پروژه ی حرفه ای محسوب میشه و نیاز به پژوهش و زمان زیادی داره.

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

CMS مخاطبین متفاوتی داره. نگاه یه Developer در مورد CMS با نگاه یه End-User خیلی متفاوت هست. همچنین کسی که فقط به جنبه ی تجاری CMS توجه میکنه و کاری به رضایت مشتری نداره هم به همین صورت هست. اما قضیه تجاری و مقرون به صرفه بودن؛ این مساله هم برای مشتری باید سنجیده شه هم برای تولید کننده: برای مشتری مسلما با صرفه هست چون تولید کننده سودش رو از فروش محصول در تعداد بالا میبره در نتیجه قیمت تمام شده به مراتب پایین میاد و فقط ممکنه نارضایتی مشتری از کیفیت باشه و اینکه به نیازهاش اونطوری که دوست داشته پاسخ داده نشده(دقت کنید پاسخ داده شده ولی این پاسخ مطلوب مشتری نبوده) اما برای تولید کننده شرایط یه ذره پیچیده هست. در این حالت چند نوع تولیدکننده داریم؛ بد نیست نگاهی هم به بازار اقتصادی این تولیدکننده ها داشته باشیم:

• گروه اول شرکت هایی هستن که روی CMS های آماده کار میکنن و اونها رو توسعه میدن؛ اگر این گروه فقط بخوان رو همین قضیه تمرکز کنن موفقیتشون متناسب با شرایط اقتصادی و سیاسی پیش میره ولی عموما فقط هستن و کارشون رو ادامه میدن. این گروه بیشتر از روی تبلیغات و روابط پروژه میگیرن و قیمت پروژه ها نهایت زیر ۵،۶ میلیون هست.

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

• گروه سوم شرکت هایی هستن که بعد از چند سال تجربه موفق در بازار و با یه رزومه ی کاری نسبتا خوب تصمیم به تولید یه CMS میگیرن. این گروه از دو گروه قبل به مراتب موفق ترن به چند دلیل. دلیل اول این هست که اولا بازار رو میشناسن، با مشتریان زیادی در ارتباط بودن و نیازهای مشتری رو بخوبی حس کردن و میدونن چه هدفی دارن. دلیل دوم اینه که دقیقا میدونن چه نیازی از مشتری در قالب یه CMS پررنگ تر بهش پاسخ داده میشه و در نهایت تجربه فنی قبلیشون رو اهرم میکنن که این کار باعث میشه در مدت زمان کمتری به نسبت گروه دوم پروژه رو تموم کنن و هزینه تمام شدشون خیلی پایین تر دربیاد. این گروه با توجه به تجربه چندسالشون خیلی راحت تر از دو گروه قبل جذب مشتری میکنن. عموم پروژه های نرم افزاری نون و آب دار در مناقصات معرفی میشن. این گروه شانس زیادی در گرفتن این پروژه ها دارن. CMS برای این گروه بهترین سود را خواهد داشت. سودهای چند ده میلیونی و طوری میشه که این شرکت ها تبدیل به قدرت های بزرگی میشن. اینها اگه برای ۴ تا پروژه ۴۰ میلیون قیمت میدادن و ۲۰ میلیون سود میکردن الان با دو سه تا پروژه اولشون هزینه تولید CMS رو جبران میکنن و از پروژه های چهارم پنجم به بعدشون فقط سود میکنن! البته این رو هم در نظر بگیرین که چند سالی که این شرکت ها کار کردن هزینه کردن و اون هزینه رو هم الان باید شامل کنید.

• گروه آخر شرکت هایی هستن که CMSهای گروه دوم یا سوم رو Resell میکنن یعنی Reseller اون شرکت ها هستن. این شرکت ها از اعتبار و نمونه سایت های گروه قبل استفاده میکنن و حتی از گروه اول و دوم هم بیشتر سود میکنن.

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

یا علی.

در اسفند ۸۸ در وب سایت بزرگ برنامه نویس به موجب سوال یکی از دوستان در مورد “شیوه ارائه طرح پیشنهادی نرم افزار”  توضیحاتی هر چند مجمل دادم که خوندنش خالی از لطف نیست:

Proposal رو باید بر اساس RFP یا Request For Proposal ای که از مشتری میگیرین تهیه کنید.
RFP از اهمیت زیادی برخوردار هست چون پیش نیاز Proposal هست و شما بر اساس اون هست که طرحتون رو ارائه میکنین. در RFP کلیاتی که مد نظر مشتری هست نوشته میشه. به نظر من RFP اولیه اگه اصولی نوشته شده باشه تا بیست درصد از حدود پروژه رو مشخص میکنه که این درصد باید حداقل به ۴۰ برسه.
معمولا مشتری توانایی و دید تهیه RFP خوب رو نداره. اون در مورد امکانات پروژه نهایت یه پاراگراف میتونه بنویسه و صرفا کلیات قضیه رو میبینه! اگه منظور از این کلیات مشخص نشه مطمئنا در برآورد قیمت و زمانبندی پروژه دچار مشکل میشین. و البته ذهنیت مشتری در تهیه RFP چیز غریب الوقوعی نیست شما وقتی میخوای بری مثلا بنز بخری هم دقیقا همین حالت رو داری مگر اینکه بری جزئیات مدل ها رو بررسی کنی. شما بعنوان مشاور می بایست به مشتری در هرچه کامل تر شدن RFP کمک کنید و حد و حدود پروژه رو تو جلساتی که با مشتری میذارین تعیین کنید و این موارد رو مکتوب کنید. معمولا تو این جلسات مطالبی که توسط مشتری بیان میشه سازماندهی خاصی نداره و هر چیزی که به ذهنش میرسه بیان میکنه. توسعه و طبقه بندی این موارد به تجربه ی شما برمیگرده که بتونین ذهن مشتری رو متناسب با امکانات پروژه و دیدی که شما از آینده کار دارین متمرکز کنین. مثلا میتونین یه فرم اولیه طراحی کنید و در اون یه سری سوالات در مورد پروژه از مشتری بپرسین و بعد روی این موارد بحث کنید و امکانات رو بسط بدین. تعامل شما با مشتری خیلی مهم هست و اگر میخواین پروژه رو بگیرین به این موارد حتما توجه کنید. حتی اگه مبلغ قرارداد ۱۰۰ تومن هست باز کارتون رو جدی بگیرین. اعتماد مشتری رو تو این جلسات هست که میتونید جلب کنید. در سیستم های نرم افزاری معمولا جا برای توسعه و شاخ و برگ دادن به امکانات زیاد هست اصلا به این فکر نکنید ممکنه مشتری به این امکانات نیاز نداشته باشه شما پیشنهاداتی که میتونین عملی کنین و احساس میکنین میتونه مفید باشه بیان کنید. حتما مثال هایی از نمونه کارهای قبلی تون رو برای مشتری عنوان کنین تا بهتر بتونه با موضوع آشنا شه.
بعد از اینکه به یه RFP نسبتا خوب رسیدین حالا یه وقتی رو از مشتری بگیرین برای ارائه طرح پیشنهادی یا همون Proposal.
اون چیزی که باید در Proposal باشه بسته به شرایط پروژه میتونه متفاوت باشه ولی کلیاتش اینا هستن:

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

خیلی از دوستان در مورد قید کردن خدمات پشتیبانی نرم افزار در پروپوزال سوال می پرسن در جواب باید بگم فقط اشاره ای به خدمانت پشتیبانی کنید کافی هست چون در صورت لزوم در قرارداد اصلی میتونید بهش بپردازید. پشتیبانی به نوع پروژه و مبلغ قرارداد بستگی داره. مثلا میتونید ۲ماه پشتیبانی رایگان داشته باشین. بسته به نوع و شرایط پروژه، بطور میانگین حدود ۲۰ درصدِ مبلغ قرارداد تعرفه پشتیبانی یکساله هست(این ۲۰ درصد کاملا نسبی و تقریبی هست) منتها مستقیما لزومی نداره اینو به مشتری بگین! بعضی پروژه ها کار زیادی در پشتیانی ندارن ولی بعضی ها چرا کار زیادی میبرن تقریبا مشخص هست و در تعیین قیمت تاثیر داره.
قبل ار قرارداد چارچوب خدمات پشتیبانی رو به مشتری توضیح بدین طوریکه توقع نداشته باشه چون پول پشتیانی داده شما بعد از ۴ماه یه پروژه دیگه براش بنویسین! جزئیات خدمات پشتیبانی رو هم حتما در قرارداد مکتوب کنید.
پ.ن: بعنوان یه استراتژی غیر منصفانه، متاسفانه بعضی از شرکت ها قیمت رو پایین میدن و در قرارداد، بند پشتیبانی رو ذکر میکنن و توش اینجوری مینویسن که قیمت خدمات پشتیانی طبق توافق اعلام میشه و تحت عنوان متمم این قرارداد پس از توافق طرفین امضاء میشه. مشتری هم اغلب به این بند زیاد گیر نمیده بعد قیمت پشتیانی رو بالا میدن و چون کار مشتری هم گیره مجبور میشه قرارداد ببنده.

موفق باشید.

عنوان پست جذابه نه؟ یه مطلب جالبی در یکی از سایت های موسیقیایی به معرفی یکی از دوستان خوندم خیلی خوشم اومد. بد نیست شما هم بدونید:

در هر موجود زنده آهنگی ویژه نوشته شده است و در تمام هستی، همه مشغول نواختن آهنگی منحصر‌‌به‌فرد هستند. در انسان، هر ژن (و پروتئین مربوط به آن) خود، آهنگی پیچیده می‌سازند و بدین سان، هر انسان تبدیل به کنسرت باشکوهی می‌شود، در حالیکه خود در کنسرت آفرینش یک آهنگ است. کلمة Universe (به معنای جهان) که در زبان انگلیسی برای توصیف بی‌نهایت و فضای لایتناهی به کار می رود از دو جزء UNI به معنی یک و Verseبه معنی آواز ساخته شده است؛ جهان یعنی یک آواز٫ به تازگی دانشمندان علم ستاره‌شناسی، بعد از تحقیقات وسیع و طولانی، به این نتیجه رسیده‌اند که آفرینش نه با یک انفجار عظیم (به نام بیگ بنگ) که با نوایی آرام آغاز شده است. نوایی که به تدریج منتشر شده و اکنون در تمام فضا جریان دارد. محققان در دانشگاه کمبریج نیز دریافته‌اند که خورشید کهکشان پرسیوس آوازی خاص و ریتمیک می‌خواند. (۱) اصوات و نواها نه تنها در اعماق فضا، بلکه در مولکولها و اتمها نیز یافت شده‌اند. دکتر دیوید دیمر (۲) زیست شناس و سزوان ژاندر (۳) موسیقی دان، سراع شگفت‌انگیزترین مولکول حیات یعنی DNA رفته‌اند. این ایده کهDNA و موسیقی ممکن است با یکدیگر مرتبط باشند برای اولین بار توسط دکتر سوسومواوهنو (۴) مطرح شد. DNA نردبانی مارپیچ است که از یکسری رمز تکرار شونده تشکیل شده است. رمزهایی که با ترجمه بخش اندکی از آن، پروتئین‌ها و در نهایت موجودات زنده شکل می‌گیرند. DNA زبان رمز مشترک در بین تمامی موجودات زنده روی کرة زمین می‌باشد، در آغاز حیات تاکنون، و راستی این زبان مشترک چه می‌گوید؟ دکتر دیمر و ژاندر، در طی آزمایشات علمی و با ثبت ارتعاشات مولکول DNA به وسیله اسپکترومتر مادون قرمز و تبدیل فرکانسها به نت موسیقی، سعی کردند این زبان مشترک را به صوت ترجمه کنند.(۵) و حالا سؤال این است: آیا این اصوات و نتها، ملودیک و آهنگین هستند و یا DNA تنها مجموعه‌ای نامنظم و تصادفی از صدا و فرکانسهاست؟ آنها فرکانسهای DNA یک سلول را به نت ترجمه کرده و شروع به نواختن کردند. نتیجه شگفت‌انگیز بود، یک موسیقی بسیار زیبا! ژاندر در این رابطه می‌گوید: «برخی از این ترکیبات فرکانسها، بسیار حیرت‌انگیز بودند. با شنیدن آنها من به موسیقی زندگی خودم گوش می‌دادم. بسیاری از افرادی که به موسیقی DNA گوش دادند، کاملاً هیپنوتیزم و مسحور شده‌اند و بسیاری دیگر نیز ساعتها گریسته‌اند. برخی دیگر اذعان کرده‌اند که این موسیقی نوایی از درون آنهاست و آنهایی که با موسیقی کلاسیک آشنایی داشتند به شباهت موسیقی DNA با آثار نوابغی چون باخ، برامس، شوپن و…اشاره کرده‌اند. دکتر اوهنو در این باره می نویسد: «ملودی های DNA با عظمت و الهام بخش می باشند. بسیاری از افرادی که برای اولین بار این موسیقی را می شنوند، شروع به گریه می کنند. آنها نمی توانند باور کنند که بدنشان – که تا حالا اعتقاد داشتند فقط تجمعی از مواد شیمیایی است – شامل چنین هارمونی های معنوی و الهام بخشی باشد. نه تنها می توان با DNA موسیقی ساخت، بلکه حتی امکان معکوس کردن فرایند نیز ممکن است. به بیان دیگر شما یک بخش از موسیقی را برداشته و نت ها را به واحدهای سازنده DNA (نوکلئوتیدها) برمی گردانید . در پایان نتیجه شبیه یک رشته از DNA می شود. اوهنو تلاش کرد تا با قطعه شوپن این کار را انجام دهد. در پایان نتیجه شبیه یک ژن سرطانی شد! دانشمندان از نتایج این یافته ها در تحقیقات پزشکی نیز استفاده کرده اند. اگر شما هم اهمیت دنبال کردن این آواها را بدانید ممکن است به این نتیجه برسید که با بررسی دی ان ای در تریلیونها سلول بدن و دانستن نوسانات آنها شاید راهی برای بیش از پنج میلیون نفری که از سال ۱۹۹۰ مبتلا به سرطان تشخیص داده شده اند، پیدا شود. فابین مامن یک متخصص بیوانرژی است که با کمک هلن گریمال بیولوژیست و موسیقی دان، بیش از یک و نیم سال بر روی افکت های سلولهای سرطانی در مرکز ملی فرانسه که یک مرکز معتبر تحقیقات اند است کار کرده اند. آنها به این نتیجه رسیده اند که سلول های بافتهای سرطانی صداهای مغشوش و ناهنجاری تولید می کنند. و علاوه بر این در آزمایشات بسیاری ثابت شد که قرار گرفتن سلولهای سرطانی در معرض صداها و امواج صوتی، تغییراتی اساسی در آنها ایجاد می کند،صداهایی که آوادرمانی را به عنوان یک پتانسیل قوی درمانی برای این نوع بیماریها و موارد بسیار دیگری مطرح می کند. مامن همچنین تحقیقاتی را بر روی دو بیمار مبتلا به سرطان سینه دنبال کرده است. هر خانم به مدت سه ساعت در روز در طول دوره یک ماهه تحت آوادرمانی (موسیقی درمانی) قرار گرفتند. پس از اتمام دوره درمان، تومور یکی از آنها کاملا ناپدید شد، اما بیمار دوم مجبور شد تومور را جراحی کند. جراح او گزارش می دهد که اندازه تومور کاملا کوچک شده بود و تا حد بسیار زیادی هم تحلیل رفته بود. از این یافته ها به این نتیجه می رسیم که وقتی اندامهایمان بصورت هماهنگ آواز می خوانند ما سلامت هستیم و وقتی که آنها خارج از تنظیمشان آواز می خوانند ما احساس بیماری می کنیم. و این داستان شگفت‌انگیزتر می‌شود اگر بدانیم که تمام سلولهای بدن یک موجود زنده، دارای یک نوع DNA منحصر به فرد هستند و DNA هر موجود (با وجود زبان و ساختار مشترک)، با DNA دیگری متفاوت است و این بدین معناست که در هر موجود زنده آهنگی ویژه نوشته شده است و در تمام هستی، همه مشغول نواختن آهنگی منحصر‌‌به‌فرد هستند. تصور کنید چگونه «۱۰۰ تریلیون سلول در بدن هر انسان در حال خواندن آوازی یگانه هستند و شاید این آواز، هم‌ آوا با آواز کهکشان پرسیوس باشد! چرا که نه؟ موسیقی‌دان و رهبر ارکستری که نتها را در آغاز آفرینش نوشته است یکی بوده و یکی هست. نکات جالب توجه دیگری نیز در این تحقیقات و یافته‌ها وجود دارد. هر چه موجود از نظر تکاملی (تکامل در زیست‌شناسی) پیشرفته‌تر بوده، موسیقی DNA آن نیز پیچیده‌تر شده است. یک جاندار تک سلولی با داشتن DNA کمتر و پروتئین‌های محدودتر، موسیقی ساده‌تری ایجاد می‌کند. در حالیکه در انسان، هر ژن (و پروتئین مربوط به آن) خود، آهنگی پیچیده می‌سازند و بدین سان، هر انسان تبدیل به کنسرت باشکوهی می‌شود، در حالیکه خود در کنسرت آفرینش یک آهنگ است. و راستی در کنسرت بزرگ جهان ما آهنگ را چقدر هم‌آهنگ می‌نوازیم؟ آیا، هم آواز با هستی و خیره به دستان رهبر ارکستر می‌نوزایم؟ آیا با هر حرکت آرام او، آرام و با هر اشارة سریع، تند می‌زنیم؟ شاید هم ساز خودمان را می‌زنیم؟ سایت هایی که می توانید در آنها اطلاعات بیشتری در مورد این موضوع پیدا کنید و به موسیقی دی ان ای گلبولهای قرمز و بعضی دیگر از انواع سلول ها گوش دهید:

yourdnasong.com

oursounduniverse.com

dnamusic.com

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

ترجمه: فروغ بصیرت

تدوین و تالیف: سارا یوسف پور

بیست و هشتم فروردین هشتاد و نه

این مطلب از اینجا نقل شده بود.

موفق باشید.

زندگی ریاضیات است!
اگر بدانیم چگونه خوبی ها را جمع کنیم، بدی ها را کم کنیم،
شادی ها را ضرب کنیم، غم ها را تقسیم کنیم،
نفرت را به زیر رادیکال ببریم و عشق را به توان برسانیم
می توانیم معادله چگونه زیستن را حل کنیم…

…………………………………………………………………….

التماس به خلق ِ خدا خفت است؛ اگر برآورده شود منت است اگر برآورده نشود ذلت است.
التماس به خدا شجاعت است؛ اگر برآورده شود رحمت است اگر برآورده نشود حکمت است.

منبع ناشناس