تبلیغات
مدیر پروژه - مطالب ابر مدیریت علمی

درباره وبلاگ

آرشیو

آخرین پستها

طبقه بندی

نویسندگان

ابر برچسبها


Admin Logo
themebox Logo


تئوری پنجره شکسته

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

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

شما چند تا پنجره شکسته در پروژه دارید؟




نویسنده :نیما نیازمند
تاریخ:جمعه 10 آبان 1392-01:46 ب.ظ
نوع مطلب : علم مدیریت 


منطق ، عقل سلیم و روش علمی (بخش دوم)

- حالا سوال اینه که چرا سریع پیش رفتن، با اصولی کار کردن در تضاده، این فرض از باوره یا حقیقت؟
- به نظر می یاد اصولی کار کردن زمان بیشتری می گیره. زمان بیشتر برای پیدا کردن راه حل خوب و در نتیجه کار بیشتر برای پیاده سازی آن.
- به عنوان برنامه نویس وقتی می خوام feature جدید اضافه کنم به دو مورد فکر می کنم: همه ما می دونیم با هر درخواست جدید که از طرف مشتری می شه، یه بخشی از سیستم تغییر می کنه پس سعی می کنم طوری کد بنوسیم که در آینده تغییر کمتری داشته باشم ، دوم اینکه بخشی از کارم مرتبط با کد های موجود می شه که ممکنه شخص دیگه ای نوشته باشه که به جزئیاتش آشنا نباشم یا کاره خودم باشه ولی یادم نیاد چیکار کردم! اکثرا مجبورم کد موجود رو تغییر بدم و این احتمال وجود داره که یک قسمتی رو از کار بندازم. یونیت تست ها تا حد زیادی می تونن کمک کنن ولی برداشتم اینه که نوشتن تست زمان گیره برای همین یونیت تست ها رو یه کار جانبی می دونم. ترجیح می دم یه کار موقتی انجام بدم که سریع تر باشه مثلا یکپارچگی با کل سیستم رو نادیده بگیرم یا هماهنگی با بقیه رو . هرچند دفعه بعد یک نفر دیگه شایدم خودم سر کد های موقتی گیر کنه در نتیجه کلاف این اسپاگتی بیشتر می شه. برای اینکه تغییر کمتری داشته باشیم باید بیشتر فکر کنیم که زمان بیشتری می گیره از طرفی برای این که سریع تر کار کنیم باید کمتر فکر کنیم که در آینده تغییرات بیشتری داریم یه تضاد دیگه!
- همیشه دنبال انتخاب راه حل ایده آلی که همه حالت ها رو جواب بده هستیم ، ولی اگه پیش بینی برای تغییرات آینده درست نباشه تمام زمانی که برای فکر کردن را حل ایده آل صرف شده هدر میره و کدی داریم که استفاده نمی شه و دوباره برای تغییرش زمان مورد نیازه!
- دقیقا ، تغییر جز توسعه نرم افزاره برای همین آجایل رو انتخاب کردیم اگه تغییر رو به عنوان واقعیت نرم افزا بپذیریم تلاش برای تغییرات کمتر بی فایده است!
- راهی هست که بشه کد رو به راحتی تغییر داد؟
- تغییر همیشه سخت تر و زمان گیر تره بهترین راه اینه که اصلا چیزی رو تغییر ندیم.
- ها!!!
- جدی می گم! جا انداختن یه سبک جدید مشکلات خودشو داره ، تا کاملا عادت بشه همش روش قدیمی پیاده می شه. بنابراین باید یه قاعده ساده باشه که هر کسی با یاد آوریش به سوی کد تغییر پذیر سوق داده بشه و اونم اینه که دیگه هیچ کس نباید کد نوشته شده رو تغییر بده باید کد جدید بنویسه.
- اینطوری که هر کسی ساز خودشو می زنه و  کلی کد تکراری پیدا می شه!؟
- اگه هنگام نوشتن کد به abstraction, re-usability, separation of concern توجه کنیم کد تکراری نخواهیم داشت!
- دیگه خیلی فنی شد ، جزئیات فنی برای تیم تولید. ولی از کجا مطمئینی حواب می ده ، فرصتی برای آزمون و خطا نداریم.
- اتفاقا منم از آزمون و خطا بدم می یاد در روش علمی یه مرحله داریم به اسم آزمایش علمی. همون طور که می دونی هیچ وقت نمی شه درستی یک فرضیه رو صد درصد اثبات کرد و ممکنه بعدها نادرستیش ثابت بشه و اینکه برای اثبات درستی می تونیم صد ها دلیل بیاریم ولی یک دلیل ، نادرستی رو ثابت می کنه. بنابراین کاری که باید انجام بدبم اینه که ثابت کنیم فرضیه نادرست نیست ولی چون راجبه علم محض صحبت نمی کنیم می شه از دلیل و منطق برای اثباتش استفاده کرد.
به طور خلاصه : بخشی از زمان برای پیدا کردن راه حل ایده آل که همه حالت ها رو جواب یده و بعدا نیاز به تغییر نداشته باشد صرف می شه و بعد از اون اگه راه حل جواب نده دوباره برای درست کردنش زمان صرف می کنیم در نتیجه برای ذخیره زمان راه حل موقتی ولی سریع تر پیدا می کنیم که سر فرصت بعدی درست کنیم. یعنی تغییراتی رو برای آینده باقی می زاریم که خودش کارو مضاعف می کنه. به عنوان راه حل فرض می کنیم اگر تغییر رو به عنوان واقعیت قبول کنیم و طوری کد بنویسیم که در آینده به راحتی و سرعت قابل تغییر باشه زمان زیادی صرفه جویی می شه و بهترین راه برای ایجاد کد تغییر پذیر ، تغییر ندادن کد موجوده. برای این کار باید روی interface ها متکی بشیم و به جای تغییر کد موجود پیاده سازی جدیدی رو برای اینترفیس ها داشته باشیم اگه فرضمون درست نباشه سرعت توسعه زیاد نمیشه از اونجایی که دیگه زمانی برای تغییرات و پیشبینی صرف نمی شه و پیش بینی کردیم که این زمان از زمان تولید کسر می شه ، پس بازم دلیلی وجود داره که زمان می گیره می شه.
- سوال اینه که چه دلیلی؟
-الان نمی تونم موردی پیدا کنم ، اگه موردی باشه فرضیه نادرسته. البته ممکنه پیاده سازی روش جدید وقت گیر باشه که می تونیم با یه جلسه آموزش 2 ساعته و پیاده سازی روی یه فرم تست کنیم یعنی تست در مقیاس کوچک.
- پس اون فرم هم جز لیست کار ها اضافه شد؟
- یه جلسه با تیم تولید می زارم بعد راجب اون فرم صحبت می کنیم.
- دقیقا روش علمی رو دنبال کردیم 1- شناسایی مشکل با پیدا کردن ریشه مشکل 2- شکل دادن یک فرضیه به عنوان راه حل با باور این که هیچ تضادی وجود نداره و به چالش کشیدن فرضیاتمون 3- اثبات فرضیه با سعی در اثبات نا درست بودن آن.
- منطق ، عقل سلیم ، روش علمی
- گفتی دقیقا چه منابع علمی رو خوندی
- فکر کنم به مدیریت فروش علمی علاقه مند شدی
- چرا که نه


پا نوشت : برای پیاده سازی با این روش باید pattern ها و principal های زیر رو استفاده کنید.
SOLID
Separation of concern
Law of Demeter
Keep it simple stupid
you aren’t’ gonna need it
don’t repeat yourself





نویسنده :نیما نیازمند
تاریخ:یکشنبه 24 شهریور 1392-10:01 ق.ظ
نوع مطلب : علم مدیریت 


منطق ، عقل سلیم و روش علمی (بخش اول)

-  یکی از مشتری ها یه فرم ساده برای ورود یه سری اطلاعات می خواد
- الان اصلا نمی رسیم کار جدیدی شروع کنیم ، به سختی یتونیم کارای موجود رو سر وقت برسونیم!
- خیلی وقت نمی گیره ، یه فرم ساده ست. یه ساعته در می یاد ، بعدا جزء سیستم موجود می شه.
- یک ساعت !!! همیشه با یه فرم ساده شروع می شه ، همین فرم ساده نیاز به حذف و ویرایش و نمایش داره که به چشم نمی یاد. بعد گزارش و انواع شرایط  و گردش کار و ...
- خودت اجایل رو انتخاب کردی، گفتی می شه اولویت ها رو تغییر داد.
- الان که اولویت چیزی رو عوض نکردی داری به کارای (Task) موجود، یه کار جدید با اولویت بالا اضافه می کنی! می شه اولویت ها رو عوض کرد ولی نمی شه کاری رو نصفه رها کرد. می تونیم تسک جدید رو با یه تسک انجام نداده عوض کنیم یا باید صبر کنی برای iteration بعدی. هم می تونیم نیروی جدید بگیریم.
- نه هیچ کدوم نمیشه ، حالا فعلا یه چیزی در بیاد کارشون راه بیوفته تا بعد. رو سرم سوار شدن!
- فقط این نیست ، این کار کیفیت کد رو پایین می آره. دیدن یه فرم ساده با یه سیستم فرق می کنه بعد feature های دیگه می خوان ، اونم با عجله. همیشه با یه چیزه ساده شروع می شه و بعد تبدیل به اسپاگتی می شه. نگهداری سیستم کابوس می شه. با این ترافیک کاری که ایجاد کردی هیچ وقت نمی شه کد های قبلی رو باز بینی کنیم. حتی اگه کسی یه باگ ببینه مجبوره نا دیده بگیره چون وقت نداره درستش کنه!
- قبول، ولی به مشتری نمی شه نه گفت. محصول رقیبها آمادست ممکنه سویچ کنن. سنگ تراش یه چیزی بتراش. مشتری یه چیزی می خواد که کار کنه براش مهم نیست که داخلش اسپاگتیه یا اصول.
- قراره مشکل رو حل کنیم یا به هم پاس بدیم؟
- راه حلی داری !؟
- برای این که مشتری رو راضی نگه داریم باید با سرعت بیشتری کار کنیم در نتیجه کیفیت کد پایین می یاد و از طرفی برای این که نرم افزار قابل نگه داری داشته باشیم باید کد با کیفیت داشته باشیم که اونم سرعت تولید رو پایین می آره.
- دنیا پر از چیز های متضاده، باید یک توازن بین این دو رو انتخاب کنی تا ...
- کاریه که الان داریم انجام می دیم. فکر می کنم به خاطر همین ایجاد توارن در تضاد، کارا بد پیش می ره. احتیاج به سرعت نور داریم تا با این منابع کم کارو پیش ببریم حتی با اجایل هم نمی تونیم سریع تر پیش بریم. یه چیزی به فکرم رسید چند وقته دارم مقالات علمی می خونم، باید از زاویه علمی به مشکل نگاه کنیم.
- خوب ؟
- کل گرایی (Holism) یعنی یک سیستم رو باید بصورت کل ببینیم نه مجموعه ای از اجزا. شناخت اجزا باعث شناخت کل نمی شه ، کل از با هم بودن اجزا و تعامل بین آنها بوجود می آد. مثلا آب که از 2 مولکول هیدروژن و 1 مولکول اکسیژن درست شده ولی شناخت مولکول های تشکیل دهندش باعث شناخت آب نمیشه. متاسفانه چون سیستم ها اکثرا پیچیده هستن و درکشون سخته ما اونا رو به اجزاشون تقسیم می کنیم و هر جز رو جدا بررسی می کنیم بنابراین سیستم او طوری که هست فهمیده نمی شه و در نتیجه راه حل درست پیدا نمیشه.
- چطوری می شه بدون تقسیم یه سیستم پیچیده ، کل رو درک کرد؟
- اگه پیچیدگی رو زیادیه اجزا بدونیم مشکل می شه درکش کرد. برای مثال مفهوم حرکت ، پیچیده ست ولی نیوتن با سه قانون حرکت اونو به سادگی بیان کرد. برای فهم سیستم باید دنبال اجزایی باشیم که تغییر اونها باعث تغییر در کل سیستم می شه.
- یعنی باید ریشه ی مشکل(root cause)  رو پیدا کنیم؟
- مشکلات معمولا علائمی هستند که به خاطر درست کار نکردن یکی از علت های ریشه ای (common causes) بوجود می یان. اگه سیستم رو به این شکل ببینیم یعنی فقط اجزای کمی هستند که روی کل اثر می گذارن ، سیستم نه تنها پیچیده نیست بلکه بهبود سیستم راه حل ساده ای داره.
- داره جالب می شه!





نویسنده :نیما نیازمند
تاریخ:جمعه 15 شهریور 1392-03:00 ب.ظ
نوع مطلب : علم مدیریت