Proof of Concept - PoC

 

فردا 15 نفر مهمان دارید و می خواهید برای آنها غذایی را آماده کنید که برای اولین بار می خواهید پخت آن را تجربه کنید. فرض کنید خورش فسنجان

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

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

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

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

Evolutionary Software Contracts

یکی از مشکلاتی که پیمانکاران تولید نرم افزارهای سفارشی (Bespoke) با آن درگیر هستند عدم مطابقت متدولوژی تولید نرم افزار با قرارداد منعقد شده با کارفرماست.

بسیاری از تولید کنندگان نرم افزار امروزه متدولوژیهای تکاملی (Evolutionary) را برای تولید انتخاب می کنند. هر چند بسیاری از کارفرمایان نسبت به نتیجه مثبت این گونه متدولوژی ها آگاه هستند، اما به دلایل مختلف (نظیر تمایل به کنترل پروژه و هزینه ها به شکل کلاسیک) هنوز مایل به انعقاد قرارداد مقطوع (Fixed Price) هستند.

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

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

تفاوت ها و شباهت های محیط کاری - تهران تا سیدنی (4)

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

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

در مورد پروژه های نرم افزاری نیز روش مشابهی را تجربه کرده ام. از تحلیل تا طراحی و پیاده سازی و تحویل همین تفکر دنبال می شود محصول پیشین به تدریج از دور خارج شده (Phase Out) و محصول جدید جایگزین آن می شود (Phase In).

دمی درنگ

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

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

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

به عنوان یک نمونه ساده، "رسیدن به وزن مطلوب" را در قالب یک پروژه بررسی می کنیم:

۱. حوزه (Scope) هدف باید مشخص، واقع بینانه و قابل دستیابی باشد: "کم کردن وزن به میزان ۸ کیلوگرم"

۲. زمان ابتدا و انتهای پروژه (هدف) باید تعیین شده باشد: "شروع از فردا - پایان ۸۰ روز دیگر"

۳. فازهای رسیدن به هدف باید مشخص و دارای نقاط کنترلی (Check Point - Milestone) باشد: "هر ۱۰ روز ۱ کیلو از وزنم کم خواهد شد"

۴. منابع لازم برای رسیدن به هدف (هزینه، میزان تلاش لازم...) باید به شکل واقع بینانه تخمین زده شود: "میزان مصرف غذاهای پر چربی به نصف رسیده و میوه و سبزی جایگزین آن خواهد شد - N تومان برای ثبت نام در باشگاه ورزشی X هزینه خواهد شد"

۵.  کیفیت مطلوب تعیین شده باشد: "کم کردن وزن نباید بر سلامتی من تاثیر منفی داشته باشد. در نتیجه طول مدت کم کردن وزن را خیلی کوتاه مدت تعیین نمی کنم و در صورت امکان برنامه غذایی خود را با یک متخصص تغذیه مورد مشورت قرار می دهم"

۶. ریسک ها و محدودیت ها باید تا حد امکان ارزیابی و تحلیل شود و روشهای کمینه ساختن آنها یا دستکم کاهش اثر آنها شناخته شود: "پیش از شرکت در مهمانی ها که غذاهای پرچربی و وسوسه برانگیز (!) وجود دارد خود را با غذاهای مناسبتر سیر می کنم - از ۱۰ روز دیگر به مدت ۲ هفته به دلیل مشغله کاری مجبور به اضافه کاری هستم و نمی توانم به باشگاه ورزشی بروم، در نتیجه در آن دوره میزان مصرف غذای خود کمی کاهش خواهم داد"

۷. از زمان آغاز تا انجام، مرتب مورد ارزیابی قرار گیرد و پیشرفت آن کنترل شود: "هر ۲ روز یکبار وزن خود را کنترل کرده و هر ۱۰ روز یکبار اطمینان حاصل می کنم که یک کیلو از وزن خود را از دست داده ام"

۸. در صورت لزوم برنامه تعیین شده بروزرسانی شود: "پس از گذشت یک ماه: قرار بوده پس از گذشت ۳۰ روز ۳ کیلوگرم از وزن کاسته شود اما ۲ کیلوگرم کم شده است. در نتیجه برنامه غذایی روزهای آینده کمی مشکل تر شده و یا طول پروژه به ۹۰ روز افزایش می یابد"

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

ویکی چیست؟

در ویدئوی کوتاه زیر نحوه عملکرد ویکی (Wiki) و استفاده آن در جهت بهبود همکاری میان افراد یک تیم (Collaboration) به شکلی ساده و جذاب شرح داده شده است:

http://www.commoncraft.com/video-wikis-plain-english

تمرکز بر نتیجه - نه فرآیند

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

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

در همین زمینه مطلب زیر را از سایت Microsoft کپی کرده ام:

 Promote results and benefits, not processes. Most people don’t care how you help them reach their goals, as long as you do it with integrity, efficiency, and within their budget. Instead of talking about how you work, be clear about your expertise and the changes people can expect from working with you. Get into the habit of asking clients for testimonials and referrals and consider writing (or hiring someone to write) case studies on successful engagements you’ve had. The most effective promotion comes from satisfied customers.

 

سندروم پنجره شکسته (Broken Window Syndrome)

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

 می دانید اگر آینه ترک خورده را همان روز تعویض کرده بودید احتمالا امروز ماشین شما هیچ یک از اشکالات مزبور را نداشت و به علاوه از تمیزی برق می زد؟

 داستان اشاره شده نمونه ای از نظریه پنجره شکسته بود. این نظریه محصول فکری دو جرم شناس آمریکائی (Criminologist) بود به اسامی جمس ویلسون (James Wilson) و جورج کلینگ (George Kelling). این دو استدلال می کردند که جرم نتیجه یک نابسامانی است. اگر پنجره ای شکسته باشد و مرمت نشود آنکس که تمایل به شکستن قانون و هنجارهای اجتماعی را دارد با مشاهده بی تفاوتی جامعه به این امر دست به شکستن شیشه دیگری می زند. دیری نمی پاید که شیشه های بیشتری شکسته می شود و این احساس آنارشی و هرج و مرج از خیابان به خیابان و از محله ای به محله دیگر می رود و با خود سیگنالی را به همراه دارد از این قرار که هر کاری را که بخواهید مجازید انجام دهید بدون آنکه کسی مزاحم شما شود.

 ویلیام برتون (William Bratton) سمت ریاست پلیس متروی نیویورک را برعهده داشت شد. برتون نیز از طرفداران تئوری "پنجره شکسته" بود و به آن ایمانی راسخ داشت. در این زمان ١٧٠٫٠٠٠ نفر در روز به نحوی از پرداخت پول بلیط می گریختند. از روی ماشین های دریافت ژتون می پریدند و یا از لای پره های دروازه های اتوماتیک خود را به زور بداخل می کشانیدند. در حالیکه کلی جرائم و مشکلات دیگر در داخل و اطراف ایستگاههای مترو در جریان بود برتون به مقابله مسئله کوچک و جزئی پرداخت بهاء بلیط و جلوگیری از فرار مردم از این مسئله کم بها پرداخت.

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

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

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

 مطلب اخیر را به شکل کامل در اینجا بخوانید.

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

شکاف ارتباطی میان مشتری و توسعه دهندگان نرم افزار

در کنفرانس QCon سخنرانی یک ساعته ای حول شکاف ارتباطی موجود میان مشتری و توسعه دهندگان نرم افزار توسط Martin Fowler و Dan North ارائه شده است. دوستانی که نوشته های Martin Fowler را دنبال می کنند با لحن روان و شوخ طبع ایشان آشنایی دارند که در این سخنرانی نیز آنرا تجربه خواهند کرد.

Summary:
In this presentation filmed during QCon London 2007, Martin Fowler and Dan North talk about the communication gap existing between the developers and the customers or users. Closing this gap is extremely important in order to create successful software.

برای مشاهده آن اینجا را کلیک کنید.

Ever Changing Requirements

There's a refrain I've heard on every problem project I've run into. The developers come to me and say "the problem with this project is that the requirements are always changing". The thing I find surprising about this situation is that anyone is surprised by it. In building business software requirements changes are the norm, the question is what we do about it.

Martin Folwer: The New Methodology

http://martinfowler.com/articles/newMethodology.html

 

فلسفه دمینگ

نام ادوارد دمینگ (1993-1900) را احتمالا شنیده اید. برخی ادوارد دمینگ را "پدر علم مدیریت کیفیت" و برخی وی را با لقب "پدر مدیریت کیفیت ژاپن" می شناسند. ژاپنی ها به آقای ادوارد دمینگ احترام فراوان می کنند چرا که بخشی از پیشرفت کشور خود را مدیون او هستند. خلاصه فلسفه دمینگ در فرمول ساده زیر خلاصه می شود:

 

 

 

 

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

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

برای دستیابی به اهداف مطرح شده در این فلسفه، دمینگ 14 توصیه دارد که به برخی از آنها در زیر اشاره می شود:

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

-          عدم وابستگی به بازرسی و معاینه برای دستیابی به کیفیت و ایجاد کیفیت در محصول/خدمت در گام اول

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

-          بهبود ثبات و پایداری تولید سیستم به منظور بهبود کیفیت و بهره وری و همچنین کاهش هزینه ها

-          ایجاد آموزش حین کار

-          برطرف کردن هراس به هدف کارایی بیشتر افراد در سازمان

-          شکستن موانع ارتباطی میان بخش ها و دپارتمان های مختلف سازمان و انجام کار به شکل تیمی

-          القای روح حرکت به سوی تغییر و دگرگونی در همه افراد سازمان و پذیرش تغییرات با آغوش باز