آه آزادي

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

و شعر با صداي شادروان احمد شاملو

چگونه به سمت Agile حرکت کنیم؟

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

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

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

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

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

Lessons in Software from Alok Srivastava

These are my top lessons learned drawing from my years of software experience.  I am sharing them with you here.

Summary of Lessons
Here is an index of the lessons that follow:

  • Lesson 1. Software development is a team sport.
  • Lesson 2. More lines-of-code does not mean better software.
  • Lesson 3. The Cloud is an inflection point.
  • Lesson 4. Scalability, performance and diagnostic ability are better achieved at design time.
  • Lesson 5. User experience and user expectation change continuously that is why UI projects are never done.
  • Lesson 6. Software maintainability is a key to longer life for any software.
  • Lesson 7. Development process should help development produce good quality software, if it comes in your way change it.
  • Lesson 8. Take agility with a grain of salt; result –oriented software development is what agility should help you gain.
  • Lesson 9. A great software engineer never stops working.
  • Lesson 10. Know the keys to writing great software; magic isn’t one of them…

Source : shapingsoftware.com

planning poker

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

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

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

بعد از ایام عید، پیش بینی های هر دو گروه مورد بازبینی قرار گرفت. گروه کارشناسان 95 درصد فروش واقعی را تخمین زده بودند در حالیکه گروه کارمندان 99.9 درصد فروش واقعی را تخمین زده بودند. اما چگونه ممکن است که یک گروه از کارمندان به گروهی از کارشناسان خبره غلبه کنند؟

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

آیا می توانیم از روش مشابه بالا برای تخمین زدن اندازه کارها در پروژه های نرم افزاری استفاده کنیم یا نه؟ پاسخ بله است. در متدلوژهای Agile ما تکنیکی به نام planning poker برای تخمین زدن داریم که تقریبا مشابه روش بالا می باشد. در این تکنیک به جای اینکه فقط مدیران کار تخمین را انجام بدهند، کل تیم یعنی مدیران، تحلیلگران، معمارها، مدیران پایگاه داده و …. با هم اینکار را نجام می دهند.

در این روش ما مجموعه ای از کارت ها داریم، که بر روی هر کدام از آنها عددی نوشته شده است. این اعداد در اکثر موارد سری فیبوناچی یا یک سری مانند سری مقابل 0,1/2,1,2,3,5,8,13,20,40,100 می باشد.

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

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

عشق و کار

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

بری دیگه برنگردی، انشاالله

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

بگذاریم،
مهم این بود که این 17 ماه تمام بشود حالا به هر قیمتی و به هر نحوی، مهم نیست.
این 17 ماه تمام شد با همه خوبی ها و بدی هایش، با خاطرات تلخ وشیرینش و شاید با
مهمترین دستاوردش دوستان تازه، دوستی های که امیدوارم تمام نشوند.

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

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

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

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

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

کسی که نمی دانم کیست!

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

برمی
گردم، سالها به عقب در یک روز زمستانی …

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

آری،
من می دانم که نمی دانم، شاید زیباتر باشد که ندانم.

پس
بازمی گردم، می روم، قدم به قدم، پله ها، پله ها را هم پایین می روم، فقط چند قدم
دیگر، ولی دیگر کسی نیست، چرا کسی هست، کسی که نمی دانم کیست!

Google یا googol، کدام صحیح است؟

در
پاییز سال 1997، برین و پیج به این نتیجه رسیدند که موتور جستجوی بک راب به یک نام
جدید نیاز دارد. پیج در یافتن یک نام چشمگیر که قبلا مورد استفاده قرار نگرفته
باشد، دچار دردسر شده بود و لذا از شون اندرسون، هم اتاقی اش در خواست کمک کرد.
آندرسون به یاد می آورد: «من به سمت تخته سیاه رفتم و با روش طوفان مغزی شروع به
نوشتن اسامی روی آن کردم و او دائما می گفت نه، نه، نه. این کار چندین روز ادامه
داشت. او رفته رفته مایوس می شد و ما یک جلسه دیگر طوفان مغزی تشکیل دادیم. من
نزدیگ تخته سفید نشسته بودم و یکی از آخرین چیزهایی که به آن رسیدم این بود که
“نظرت راجع به گوگل پلکس چیست؟” او شکل کوتاهتر این اسم را دوست داشت.
من کلمه
G-o-o-g-l-e
را با املای غلط روی تخته سفید نوشتم
 و حالا
به چشم می آمد. لاری با آن موافقت کرد و بعدا در همان شب آن را ثبت کرد و
 روی
تخته سفید نوشت:
google.com.
شبیه یاهو یا آمازون، یک حلقه نه چندان دقیق اینترنتی به آن اضافه کرد و
 روز بعد که به دفترم آمدم دیدم تامارا یاداشتی
برایم گذاشته و نوشته است است
تو املای آن را غلط نوشته ای. درست آن باید این باشد: G-o-o-g-o-l’»

بک
راب: نام موتور جستجوی گوگل در مرحله تحقیقاتی در دانشگاه استنفورد بود.

سرگئی
برین و لاری پیج: موسسین شرکت گوگل

کتاب the google story، کتاب بسیار خواندنی در مورد تاریخچه
و
سیر تکامل شرکت گوگل
است، واقعا این شرکت سرنوشت جالبی دارد، که می تواند خیلی آموزنده باشد.خواندن این
کتاب را به دوستان توصیه می کنم البته ترجمه فارسی کتاب نیز موجود می باشد با
عنوان «سرگدشت شگفت انگیز گوگل» برای افراد مثل خودم که زبانشان زیاد خوب نیست.

هفت نصیحت مولانا

 گشاده دست باش، جاري باش، كمك كن (مثل رود)

 باشفقت و مهربان باش (مثل خورشيد)

 اگركسي اشتباه كردآن رابه پوشان (مثل شب)

 وقتي عصباني شدي خاموش باش (مثل مرگ)

 متواضع باش و كبر نداشته باش (مثل خاك)

 بخشش و عفو داشته باش (مثل دريا )

 اگرمي خواهي ديگران خوب باشند خودت خوب باش (مثل آينه )

Question Until You Understand


“Accept the explanation you’ve been given. If you’re told where the problem lies, that’s where you look. Don’t waste your time chasing ghosts.”

Suppose there’s a major problem in an application, and they call you in to fix it. You aren’t familiar with the application, so they try to help you out, telling you the issuemust be in one particular module you can safely ignore the rest of the application.
You have to figure out the problem quickly, while working with people whose patience may be wearing thin.


When the pressure is on like that, you might feel intimidated and not want to question too deeply what you’ve been told too deeply. To solve the problem, however, you need a good understanding of the big picture. You need to look at everything you think may be relevant — irrespective of what others may think.


Consider how a doctor works. When you’re not well, the doctor asks you various questions—your habits, what you ate, where it hurts, what medication you’ve been taking, and so on. The human body is complex, and a lot of things can affect it. And unless the doctor is persistent, they may miss the symptoms completely. For instance, a patient in New York City with a high fever, a rash, a severe headache, pain behind the eyes, and muscle and joint pain might be dismissed as having the flu, or possibly the measles. But by probing for the big picture, the doctor discovers the hapless patient just returned from a vacation to South America. Now instead of just the flu, a whole new world of possible diagnoses opens up including dengue hemorrhagic fever.

Similarly, in a computer, a lot of issues can affect your application. You need to be aware of a number of factors in order to solve a problem. It’s your responsibility to ask others to bear with you—have patience—as you ask any questions you think are relevant.


Or, suppose you’re working with senior developers. They may have a better understanding of the system than you. But, they’re human. They might miss things from time to time. Your questions may even help the rest of your team clarify their thinking;your fresh perspective and questions may give others a new perspective and lead them to find solutions for problems they have been struggling with.

“Why?” is a great question. In fact, in the popular management book The Fifth Discipline: The Art and Practice of the Learning Organization, the author suggests asking no fewer than five progressive “Why?”s when trying to understand an issue. While that might sound like a policy oriented more toward an inquisitive four-year-old, it is a powerful way to dig past the simple, trite answers, the “party line,” and the usual assumptions to get down to the truth of the matter.


The example given in the Fifth Discipline Field Book for this sort of root-cause analysis involves a consultant interviewing the
manager at a manufacturing facility. On seeing an oil spill on the floor, the manager’s first reaction is to order it cleaned up. But the consultant asks, “Why is there oil on the floor?” The manager, not quite getting the program, blames the cleaning crew for being inattentive. Again, the consultant asks, “Why is there oil on the floor?” Through a progressive series of “Whys” and a number of employees across different departments, the consultant finally isolated the real problem: a poorly worded purchasingpolicy that resulted in a massive purchase of defective gaskets.


The answer came as quite a shock to the manager and all the other parties involved; they had no idea. It brought a serious problem to light that would have festered and caused increasing damage otherwise. And all the consultant had to do was ask, “Why?”


“Oh, just reboot the system once a week, and you’ll be fine.” Really? Why? “You have to run the build three times in row to get a complete build.” Really? Why? “Our users would never want that feature.”


Really? Why?

Why?

Keep asking Why. Don’t just accept what you’re told at face value. Keep questioning until you understand the root of the issue.


What It Feels Like

It feels like mining for precious jewels. You sift through unrelated material, deeper and deeper, until you find the shining gem. You come to feel that you understand the real problem, not just the symptoms.

Keeping Your Balance


·
You can get carried away and ask genuinely irrelevant questions if your car won’t start, asking about the tires probably isn’t going to help. Ask “Why?” but keep it relevant.


·
When you ask “Why?” you may well be asked, “Why do you ask?” in return. Keep a justification for your question in mind before you ask the question: this helps you keep your questions relevant.


·
Don’t settle for shallow answers. “Because it used to…” is probably not a good answer.


·
“Gee, I don’t know” is a good starting point for more research not the end of the line.