بایگانی

بایگانی برای دسته ی ‘فناوري اطلاعات’

۵۸- نگرشی نو به شی گرایی

۱۹ آبان ۱۳۸۶ محمد بدون دیدگاه

دو هفته ای است که یک دوره آموزشی ۳۰ ساعته UML و RUP برای آماده سازی تیم توسعه کاربردها به عنوان راهبران پروژه‌های نرم‌افزاری هماهنگ کردم. در انتخاب استاد و محتوی دوره خیلی دقت شد. نتیجه کار هم که از دو جلسه اخیر برمی‌آید کاملا مطلوب است. خودم هم از ابتدای دوره تا جایی که کارهای اضطراری اجازه داده شرکت کردم. قبلتر هم در دوره های UML و RUP حضور داشتم، اما نمی دانم به واسطه پرکتیکال بودن مدرس است یا این یک سالی که با مسایل توسعه نرم‌افزاری اینقدر از نزدیک روبرو بودم، که گفته های آقای مهرداد برایم درس نبود٬ کلمه به کلمه‌اش رو می تونستم در فضای موضوعاتی کاملا واقعی تجسم کنم. بگذریم از اصل مطلب دور شدم. در طول دوره تعریفی از یک سیستم شی‌گرا و تفاوت آن با نرم‌افزارهای ساخت‌یافته ارایه شد که برای خودم هم بسیار تازگی داشت.

«داستان از این قراره که روزی یک نفر از دهی به شهر میاد و از قضای روزگار به یک کنسرت موسیقی میره. در بازگشت از شهر در راه به مطرب ده میرسه که داشته با پسرش ساز و دهل میزده. همین که مطرب رو می بینه بهش میگه که من توی شهر رفتم یک جایی به اسم کنسرت و کلی از همکارات رو یک جا دیدم. مطرب هم که تا به اون روز کنسرت ندیده و نشنیده بوده، با بهت می پرسه که کنسرت چیه؟

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

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

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

۵۵- معماری سازمانی در یک نگاه

۹ مهر ۱۳۸۶ محمد بدون دیدگاه

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


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

لینک دانلود فیلم:  Meetthearchitects.flv (8 MB) FLV 
Meetthearchitects.rar (10 MB) WMA

حرف آخر: قدر شبهای قدر رو باید دونست. قضای خیلی ها توی این شبها رقم می خوره. خوش به حال اونهایی که تا رسیدن به این شبها قضاشون رقم خورده و این شبها به دنبال قدر هستند. به قول یه دوستی «اگر یادت بود و باران گرفت٬ دعایی به حال بیابان کن». التماس دعا…

۴۴- گام بعدی شاید تغییر الگو

۱۳ اردیبهشت ۱۳۸۶ محمد بدون دیدگاه

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

اولین نکته اینه که اگر نگاه علمی و نه عامیانه به سطوح ادراک داشته باشیم می بینیم که انسان در جامعه اطلاعاتی میتونه صاحب چند سطح از ادراک باشه که در شکل زیر نشان داده شده.

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

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

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

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

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

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

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

۳۷- از این معماری تا اون معماری (چارچوب زکمن)

۱۹ بهمن ۱۳۸۵ محمد بدون دیدگاه

می بخشید ترافیک این روزها خیلی بالاست. اونقدر که وقت توضیح دادن هم ندارم. قول داده بودم یه دوره جدید در مورد معماری رو شروع کنم تا بعضی دوستان که با این مفاهیم آشنا نیستند هم بتونند با فضای بحث درگیر بشند و بعد با هم ادامه بدیم. یه چیزی هم نوشته بودم ولی خوشم نیومد٬ خیلی آکادمیک بود. یه کم از حالت آکادمیک درش میارم تا برای اونهایی هم که با این مفاهیم آشنا هستند مفید فایده باشه. به این دسته پیشنهاد می کنم «you have to read between lines». یه چیزی هم همین اول بگم. هر جا توی این متن نوشتم سیستم گسترده منظورم Enterprise است نه system. واقعیت اینه که واژه نزدیکتری از لحاظ مفهومی پیدا نکردم.

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

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

رویکردهای مختلفی یا بهتر بگم چارچوبهای معماری مختلفی در حوزه توسعه سیستمهای گسترده وجود داره که توی چندتا پست سعی می کنم همشون رو مرور کنم. ولی معروفترین چارچوب معماری موجود چارچوب زکمن است. زکمن یکی از نظریه پردازان برجسته در حوزه Enterprise Architecture است که چارچوب معماری خودش به نام چارچوب زکمن رو در سال ۱۹۸۷ در شرکت زیفا منتشر کرد. همونطور که می بینید ارایه قدیمیترین چارچوب معماری به تقریبا ۲۰ سال پیش بر می گرده. به همین خاطره که اصول معماری سیستمهای گسترده هنوز در حال تکوین و تکامله و نکته جالب هم تکامل spiral این مفاهیمه. به طور مثال همین چارچوب زکمن بارها مورد اصلاح قرار گرفته و تکمیل تر شده و این روند هنوز هم ادامه داره. می تونید همیشه نسخه نهایی این چارچوب رو توی سایت شرکت زیفا ببینید. اخیرا هم یک مدل سه بعدی از اون رو توی سایت گذاشتند که من خودم خیل ازش خوشم اومد.

هدف اولیه در طراحی چارچوب زکمن بیان ارتباط بین دیدگاههای مختلفی که در توسعه یک سیستم  وجود داره٬ بوده. به همین خاطر می بینیم که این تفکیک بین ذینفعان یک سیستم در ردیفهای اون به چشم می خوره. (Planner, Owner, Designer, Builder & Subcontractor)

زکمن این طور فرض کرده که هر کدوم از این ذیفنعان در مسیر توسعه سیستم باید به شش سوال پاسخ بدند٬ که پاسخ به این سوالات معماری سیستم گسترده رو نتیجه میده. این شش تا سوال what (متناظر با داده های سیستم)٬ how (متناظر با کارکردهای سیستم)٬ where (متناظر با ساخت اجزای سیستم)٬ who (متناظر با نقشهای موجود در سیستم)٬ when (متناظر با زمانبندیها و توالیهای سیستم) و why (متناظر با انگیزه و هدفها در سیستم)٬ هستند.

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

واقعیت اینه که خیلیها معتقدند اگر دو سطح اول این چارچوب رو طی کنند٬ معماری سیستم گسترده رو استخراج کردند و در ادامه باید افرادی با نقشهای طراحی و … کار را دنبال کنند. من خودم به شخصه به این نظر اعتقادی ندارم. چون کار معماری رو یک وظیفه استاتیک یا امدادی در توسعه یک سیستم گسترده نمی بینم. در واقع معمار سیستم گسترده باید بتونه با استفاده از چنین چارچوبی تکه های پازل یک سیستم گسترده رو کنار هم بچینه و اون رو تکمیل کنه فارغ از اینکه خودش این باکسها رو پر کنه. یعنی چی؟ در واقع معمار وظیفه اش چی بود؟ این که Big picture کاملی از سیستم گسترده بسازه و در مسیر توسعه اون رو حفظ و محقق کنه. این چارچوب خود Big picture عمومی سیستمهای گسترده است که در اختیار معمار قرار گرفته یا بهتره بگم اتود اولیه اون Big picture هستش. معمار سیستم گسترده باید بتونه این چارچوب رو برای سیستم خودش customize کنه و بعد برای تحقق هر کدوم از باکسهای اون برنامه ریزی کنه٬ ابزار٬ رویکرد و استاندارد مشخص کنه. تا نقشهای دیگه توی پروژه متناسب با تخصصشون اون باکسها رو پر کنند و معمار هم مسیر رو پایش کنه٬ تا تناسب سیستم و به خصوص یکپارچگیش حفظ بشه. فعلا تا همین جا بسه. روی چارچوب زکمن کارهای مختلف توسعه ای انجام شده که بعدا بیشتر در موردش صحبت می کنم.

حرف آخر: حرفی ندارم. باید برم شام بخورم.Batting Eyelashes

۲۸- مرور سناریویی از آینده

۱۷ آبان ۱۳۸۵ محمد ۱ دیدگاه

بالاخره دیروز برای اولین بار پروژه نماد رو به صورت عمومی و توی جمعی از مدیران و کارشناسان IT (اولین همایش ملی مدیریت فناری اطلاعات) پرزنت کردم. ولی نتیجه خیلی متفاوت تر از گذشته بود… اونقدر سعی کردم قضیه رو ساده تعریف کنم که همه بفهمند که بعد از پرزنت یه چند نفر اومدند گفتند این نماد رو چطور میشه دید… Sad یا می تونید یه جلسه پرزنت ازش بذارید ما دموی اون رو ببینیم. Surprise با این که هی وسط حرفهام گفتم بابا این آینده نگاری مثلا سال ۲۰۲۰ ممکنه اتفاق بیفته. اینا از این ور بوم افتادند. نه به اون قبلیها که می گفتند این یه خوابه٬ نه به اینها که فکر می کردند ما پیاده سازیش هم کردیم و آماده فروشه… به قول امیر علی «اللهم اجعل عواقب امورنا خیرا با این مدیران و کارشناسان». البته تیکه آخرش از خودمه. شاید هم تقصیر خودم باشه که این سری خیلی ساده موضوع رو مطرح کردم.

راستی یه سوتی خیلی ناجور هم وسط پرزنت داده بودم که دوستان بعدش بهم گفتند. اوایل صحبتم گویا گفتم «این ارایه هم توی زمینه آینده نگاری یه بحث تخصصیه و هم توی زمینه معماری و چون دوستانی که این جا حضور دارند عمدتا تخصصشون توی حوزه فناوری اطلاعات به صورت عامه و احتمالا اون بخش اول رو نفهمند Confused من سعی می کنم بیشتر روی بخش دوم تمرکز کنم.»

بگذریم عنوان مقاله «آینده نگاری تکنولوژی در حوزه خدمات الکترونیکی» بود. فایل پرزنت این مقاله حجمش حدود ۱۲ مگابایته چون پر شکل و مدله به همین خاطر ازش یه فایل PDF ساختم. اینترنت پرسرعت پیدا کردم فایل PPT اون رو هم میذارم. فعلا فایل متن مقاله رو نمی تونم بذارم چون گفتند تا کتاب همایش منتشر نشده جایی ندیدش. (لینک دانلود فایل پرزنت – RAR)

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

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

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

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

حرف آخر: دیروز بعد از ارایه یکی یه حرفی بهم زد که که برام جالب بود. جملش دقیق یادم نیست٬ ولی مضمون حرفش این بود که «ما همش در قید زنجیرهای بسته به دست و پای امروزمونیم٬ اونقدر که حتی وقتی یکی از پرواز میگه٬ فکر می کنیم طرف مجنونه…»