مالکیت جمعی (Collective Ownership)

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

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

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

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

فعل یا اسم

تمام تاکید من نه بر اسم ها که بر افعال است.

تا می توانی از اسم ها حذر کن،

اینکار در زبان امکان پذیر نیست، ولی در عرصه زندگی می توانی،

چون زندگی خود یک فعل است.

زندگی یک اسم نیست، واقعا “زندگی کردن” است و نه “زندگی”.

عشق نیست، عشق ورزیدن است.

پیوند نیست، پیوند یافتن است.

ترانه نیست، ترانه خواندن است.

رقص نیست، رقصیدن است.

برنامه نویسی دونفره (pair programing)

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

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

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

1.       کیفیت: در این شیوه ما کدی با کیفیت بالا خواهیم داشت چون اکثر خطاها و اشتباهات در همان مرحله اول تشحیص داده می شود.

2.       صرفه جویی در زمان: چون ما کدی با کیفیت بالا خواهیم داشت، زمان تست و تغییرات در سیستم کاهش خواهد یافت.

3.       افراد شاد: برنامه نویس های که با این تکنیک کار می کنند، اکثرا خوشحالتر و شادتر از زمانی هستند که به تنهایی کار می کنند. برای نمونه شما فشار کمتر را تحمل می کند چون همیشه کسی را در کنار خود دارید که به شما کمک کند و این باعث می شود که شما خیلی خوشحالتر باشید.

4.       اعتماد و روحیه همکاری بالا: در این شیوه شما تک و تک افراد تیم خود را به خوبی خواهید شناخت و باعث می شود که شما به آنها اعتماد کند و روح همکاری بخاطر شناخت عمق افراد بالا برود.

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

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

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

 

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

نامه

امروز چند بار اشتباه كردم؟
مي‌دانم‌ هيچ‌ صندوقچه‌اي‌ نيست‌ كه‌ بتوانم‌ رازهايم‌ را توي‌ آن‌ بگذارم‌ و درش‌ را قفل‌ كنم. چون‌ تو همه‌ قفل‌ها را باز مي‌كني. مي‌دانم‌ هيچ‌ جايي‌ نيست‌ كه‌ بتوانم‌ دفتر خاطراتم‌ را آنجا پنهان‌ كنم؛ چون‌ تو تك‌تك‌ كلمه‌هاي‌ دفتر خاطراتم‌ را مي‌داني
حتي‌ اگر تمام‌ پنجره‌ها را ببندم، حتي‌ اگر تمام‌ پرده‌ها را بكشم، تو مرا باز هم‌ مي‌بيني‌ و مي‌داني و مي‌داني‌ كه‌ نشسته‌ام‌ يا خوابيده‌ و مي‌داني‌ كدام‌ فكر روي‌ كدام‌ سلول‌ ذهن‌ من‌ راه‌ مي‌رود.

تو هر شب‌ خواب‌هاي‌ مرا تماشا مي‌كني، آرزوهايم‌ را مي‌شمري‌ و خيال‌هايم‌ را اندازه‌ مي‌گيري.
تو مي‌داني‌ امروز چند بار اشتباه‌ كرده‌ام‌ و چند بار شيطان‌ از نزديكي‌هاي‌ قلبم‌ گذشته‌ است.

تو مي‌داني‌ فردا چه‌ شكلي‌ است‌ و مي‌داني‌ فردا چند نفر پا به‌ اين‌ دنيا خواهند گذاشت.
تو مي‌داني‌ من‌ چند شنبه‌ خواهم‌ مُرد و مي‌داني‌ آن‌ روز هوا ابري‌ است‌ يا آفتابي.
تو سرنوشت‌ تمام‌ برگ‌ها را مي‌داني‌ و مسير حركت‌ تمام‌ بادها را.

و خبر داري‌ كه‌ هر كدام‌ از قاصدك‌ها چه‌ خبري‌ را با خود به‌ كجا خواهند برد.
تو مي‌داني، تو بسيار مي‌داني
خدايا مي‌خواستم‌ برايت‌ نامه‌اي‌ بنويسم. اما يادم‌ آمد كه‌ تو نامه‌ام‌ را پيش‌ از آن‌ كه‌ نوشته‌ باشم، خوانده‌اي… پس‌ منتظر مي‌مانم‌ تا جوابم‌ را فرشته‌اي‌ برايم‌ بياورد.

 

 (از طرف دوست خوبم احمد موفقی)

شی (مقاهیم شی گرایی)


شما دنیا را چگونه می بینید ؟

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

 

یک شی چست ؟

یک شی می تواند یک موجودیت فیزیکی باشد ، مانند یک کتاب ، یک صندلی. شما می توانید یک کتاب را توصیف کنید ، آنرا بخوانید و آنرا بخرید.

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

یک کتاب ، یک صندلی ، یک کار و هر شی در دنیا واقعی بوسیله دو گروه از خصوصیات مشخصی می شوند :

  1. صفات(attributes) : صفات ویژگیهای یک شی را بیان می کند. در واقع یک صفت یک ویژگی از یک شی است مانند صفت نام برای یک فرد. صفات توصیف کننده یک شی هستند و با استفاده از مقادیر صفات می توان وضعیت فعلی یک شی را بدست آورد. برای مثال یک فرد می تواند دارای صفت تاهل باشد که با استفاده از مقدار این صفت می توان وضعیت تاهل آن فرد را در شرایط فعلی بدست آورد.
  2. رفتار(behaviors): یک رفتار عملی است که یک شی توانایی انجام دادن آن را دارد. برای مثال یک شخص می تواند راه برود ، بدود ، بنشیند و هزاران کار دیگری که قادر به انجام دادن آن است که هر کدام از این کارها برای آن شخص یک رفتار محسوب می شود. یک سوال یک کتاب می تواند چه رفتاری داشته باشد. آیا یک کتاب قادر به انجام دادن کاری است تا به عنوان یک رفتار برای آن شی به حساب آید ؟ شی کتاب در حقیقت قادر به انجام هیچ کاری نیست. یک ناشر برای انتشار یک کتاب کارهای مانند ویرایش کتاب ، چاپ کتاب ، توزیع کتاب و در آخر فروش کتاب را انجام می دهد. این کارها توسط یک نفر بر روی کتاب انجام می گیرد. متدلوژی شی گرا به ما می گوید که این رفتارها را به جای فردی که این کارها را انجام می دهد را به شی کتاب تخصیص بدهیم.

مسابقه – نسخه بتا – آزمایش نرم افزار

فکر کنم چند ماه قبل یک ایمیل برایم رسیده بود که محتوایش برایم جالب بود. احتمالا اکثر دوستان نیر ایمیل های مشابه را دریافت کردند یا از متن آن که در پایین می خواهیم به آن اشاره کنم از طریق سایت های دیگر باخبر شده اند. ایمیل مربوط بود به یک مسابقه که توسط شرکت مایکروسافت پشتبانی و حمایت می شد و مربوط بود به ارائه یک مقاله در مورد ویژوال استودیو 2008 یا پیاده سازی یک برنامه در این محیط و تاکید مسابقه نیز بر روی ویژگیهای جدید این محیط مانند Linq و … بود. و جایزه مسابقه از نظر مالی فکر کنم مبلغ جالبی بود ولی دقیقا یادم رفته است که مبلغ جایزه نفر اول چقدر بود. فکر کنم آنزمان هنوز نسخه اصلی برنامه نیز ارائه نشده بود. همانروز ایمیل را به چند تا از دوستانم نشانم داد و گفتم که فکر می کنید هدف شرکت مایکروسافت از انجام این مسابقه چه می تواند باشد؟ (این سوال را حالا از تک تک شما دوستان نیز دارم) حتی یکی از دوستانی که کمی روی این سوال بحث کردیم یکی از طرفداران دوآتشه شرکت بورلند و محصولاتش بودند و می گفتند که حتی توی یک مسابقه مشابه که شرکت بورلند چند سال قبل روی محیط دلفی برگزار کرده بود جز منتخبان مسابقه بودند. ولی اکثر پاسخ دوستان، پاسخ های بود که به نظر من زیاد جالب نبودند چون خود شرکت مایکروسافت خودش می توانست بدون هیچ زحمتی خودش اینکارها را انجام دهد. یا بعضی از پاسخ ریشه ها در محیط و فرهنگی بود که ما در داخل کشور با آن روبرو هستیم. ولی یکی از دلایل عمده که به نظر من می تواند وجود داشته باشد موضوعی است که به عینا در کتاب کسب و کار به شیوه بیل گیتز (Business the bill gates way) به آن اشاره شده است (قسمت پایین از کتاب اشاره شده است ولی نوشته های با رنگ آبی نظرات شخصی من هستند):

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

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

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

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

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

منتظر نظرات شما هستم.

تقدیم به …

از جبران تقدیم به دوست عزیزم داوود:

“تو همزمان نمی توانی جوانی و شناخت جوانی را در یک آن در اختیار داشته باشی، زیرا که زندگی، جوان را از شناخت باز می دارد و جستجو درباره ذات معرفت او را از زندگی باز می دارد.”

و این نیز تقدیم به همه دوستانم:

“همه اندوه هایم را در پاییر جمع کردم و در باغ خویش دفن نمودم.

هنگامی که ماه آوریل بازگشت و تابستان فرا رسید تا با زمین ازدواج کند، در باغچه ام گلهایی در اوج زیبایی رویید که با سایر گلها تفاوت داشت.

سپس همسایگانم آمدند تا گل های باغچه ام را تماشا کنند. همه آنها به من گفتند: اگر پاییز فرا رسید و زمان بذر افشانی شد، آیا از بذرهای این گلها به ما می دهی تا در باغهایمان بکاریم؟

سوره تماشا

و به آنان گفتم:

هر که در حافظه چوب ببیند باغی

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

هر که با مرغ هوا دوست شود

خوابش آرام ترین خواب جهان خواهد بود.

آنکه نور از سرانگشت زمان برچیند

می گشاید گره پنجره ها با آه.

 

زیر بیدی بودیم.

برگی از شاخه بالای سرم چیدم، گفتم:

چشم را باز کنید، آیتی بهتر از این می خواهید؟

می شنیدم که بهم می گفتند:

 سحر میداند، سحر!

اینجا بروزرسانی شد

پرودگارا

به من آرامش ده

تا بپذیرم آنچه را که نمی توانم تغییر دهم

دلیری ده

تا تغییر دهم آنچه را که می توانم تغییر دهم

بینش ده

تا تفاوت این دو را بدانم

مرا فهم ده

تا متوقع نباشم دنیا و مردم آن

مطابق میل من رفتار کنند.

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

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

بینوایی آن است که دست خالی ام را جلوی مردم دراز کنم و کسی چیزی در آن نگذلرد. اما ناامیدی آن است که آن را در حالی که پر است، دراز کنم و کسی چیزی را از آن برندارد.

به من می گویند یک گنجشک در دست بهتر از ده گنجشک روی درخت است.

اما من به آنها می گویم: « یک گنجشک روی درخت بهتر از ده تا در دست است.»

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

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

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

حق با مشتری است یا نه؟

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

چند روز قبل برای رفع مشکل در سیستم نرم افزاری یکی از مشتریان به شرکت آنها رفته بودم، تقریبا اولین باری بود که بخاطر اینکار به یک شرکت مراجعه می کردم، و همین کار دلیلی برای نوشتن این مطلب شد. شرکت مورد نظر فکر کنم تقریبا همزمان با ورود من به رشته نرم افزار، از نرم افزار مورد نظر استفاده می کند یعنی چیزی نزدیگ به 5 سال. ولی چیزی که برای من جالب بود، سوالات بسیار ساده و پیش پا افتاده آنها در مورد نرم افزار بود که از من می پرسیدند. سوالاتی که فکر می کردم هر کسی بعد از چند ماه استفاده از نرم افزار باید خودش در جواب دادن به آنها استاد باشد (کاربران نرم افزار مورد نظر در طول این چند سال تغییر نکرده اند.!). گفتم حق با نرم افزاریها است که اغلب اعتراضات کاربران را نادیده می گیرند(حداقل در گروههای که من از نزدیگ آنها رادیده ام). ولی یک چیز باعث شد که فورا تغییر عقیده بدهم. یک متن که تازه توی یک EBook خوانده بودم، سعی می کنم بعد از این  همیشه با این موضوع به این صورت برخورد کنم. متنی را که گفتم در کتاب Practices of an Agile Developer خوانده بودم که در پایین عین متن را آوردم. فقط چند قسمت از این کتاب را مطالعه کردم کتاب بسیار جالبی بود، و از همه زیباتر شیوه نگارش کتاب بود، در کل کتاب از دو شخصیت استفاده شده است چیزی شبیه سوژه های کارتونی یک شخصیت مثبت (یک فرشته که شیوه صحیح را نشان می دهد) و یک شخصیت منفی که شیوه اشتباه برخورد با مسئله را نشان می دهد.(جملات قرمز توصیه شخصیت منفی است و جملات سبز توصیه شخصیت مثبت است).

Listen to Users

 

Users are always complaining. It’s not your fault; they’re just too stupid to read the stinkin’ manual. It’s not a bug; they just don’t understand. They should know better.”

Andy once worked for a large company that developed products for high-end Unix workstations. This wasn’t the sort of environment where you could just run setup.exe or pkgadd to install the software. You had to copy files and tune various settings on your workstation.

Andy and his team thought everything was going well, until one day Andy was walking past the tech support area and overheard a support engineer laughing loudly into the phone: “Oh, it’s not a bug; you made the same mistake everyone does.” And it wasn’t just this one engineer.

The whole department was chuckling at the poor, naïve, stupid customers.

Apparently there was a situation where you, the hapless customer, had to go tweak some obscure system file to contain a magic value, or otherwise the application would not run at all. No error message, no crash, just a big black screen followed by an abrupt exit. Granted, a line in the installation instructions mentioned this fact, but apparently some 80% of the customers missed that fact and had to instead submit to abuse via the company’s tech support line.

Whether it’s a bug in the product, a bug in the documentation, or a bug in our understanding of the user community, it’s still the team’s problem, not the user’s.

Then there was the case of the expensive manufacturing shop-floor control system that none of the users would use. It seems the first step to using the system was to log on with their name and password, and the majority of the workers in this plant were illiterate. No one have ever bothered to ask them or get their feedback, so a completely useless system was installed. (The developers in question had to retool the entire GUI to be picture-based at huge expense.)

We go to great lengths to get feedback from code using unit tests and such, but it’s all too easy to ignore the feedback from users. So not only do you need to talk to real users (not their managers or a surrogate

such as a business analyst), you need to listen to them.

Even if they sound stupid.

Every complaint holds a truth. Find the truth, and fix the real problem.

What It Feels Like

You don’t get irate or dismissive of stupid complaints; you can look past that and see the real, underlying problem.

Keeping Your Balance

• There is no such thing as a stupid user.

• There is such a thing as a stupid, arrogant developer.

• “That’s just the way it is” is not an answer.

• If the code can’t be fixed, perhaps the documentation and training

can be.

• Your users may have read all the documentation and will remember everything about your application all the time.

But probably not.

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