Y@SiN
11-19-2009, 07:16 PM
نرم ا�?زار هم مانند هر کالاي ديگري بايد ساخته شود. �?رآيند توليد آن هم مانند همه �?رآيند هاي توليد صنعتي، از "ت�?کر کارگاهي" تا "ت�?کر کارخانه اي" را طي کرده است.
به �?رآيند صنعتي که دقت کنيد، مي بينيد که بعد از آنکه بشر به اين صرا�?ت ا�?تاد که خودش نمي تواند همه کار بکند و مثلا يک کلبه را به صورت کامل بسازد، ابتدا به صورت �?ردي و در مغازه ها و کارگاه هاي تخصصي کار شروع شد، آهنگري ها، نجاري ها یا در و پنجره سازي و .... و بعد ديد که نمي تواند با این روش برج بسازد، نمي تواند خودرو را در حجم انبوه توليد کند ، طرز �?کرش را عوض کرد و کارخانه ها را ساخت تا بتوانند در يک خط توليد به صورت انبوه، کالاي استاندارد توليد کنند و مشتري ها هم عادت کردند که خود را با کالا تطبيق دهند.
همين ات�?اق در نرم ا�?زار ا�?تاد، از جايي که به صورت اختصاصي براي هر مشتري پروژه توليد داشتيم، تا بسته هاي نرم ا�?زاري (Package) که به صورت انبوه توليد مي شد و �?روش مي ر�?ت و تا ERP که مي گوييم استاندارد است و هر مشتري خودش را تطبيق مي دهد و يا سيستم به صورت کم، تغيير داده مي شود تا نياز مشتري را �?راهم کند.اين توليد هم مانند توليد هاي ديگر نياز به تحليل، طراحي و پياده سازي دارد. مديريت پروژه مي خواهد توليدش و همان مسائل رادارد.
�?رآیند مدیریت پروژه (سازماندهی، برنامه ریزی و نظارت) به عنوان یک اصل جدانشدنی از هر پروژه ای در همه صنایع (منجمله نرم ا�?زار) هم وجود دارد.
اما نرم ا�?زار به لحاظ عوامل ماهیتیش چنان با بقیه کالاهای صنعتی مت�?اوت است که می بینیم در روشهای توسعه آن تنوع زیادی وجود دارد و هر روز یک مدل جدید برای توسعه نرم ا�?زار می بینیم. این ت�?اوت ها را به طور خلاصه می توانیم شامل موارد زیر بدانیم:
1- نرم ا�?زار پیچیده است (Complexity): به تعبیری "کاهش پیچیدگی قلب توسعه نرم ا�?زار است." یک برنامه کوچک گاهی هزاران خط �?رمان می شود و توسعه آن به هر نحو مشکل است. روشهایی مانند ماژول بندی و .... آمده است، اما هنوز هم پیچیدگی یکی از مهمترین اجزاء جدانشدنی نرم ا�?زار ها و �?رآیند تولید آن است.
2- نرم ا�?زار انتزاعی است (abstraction) : شما نمی توانید به شکل �?یزیکی آن را لمس کنید و نشان دهید. نه خودتان واقعا می توانید همه آن را یکجا در دست بگیرید و مشکلتر آنکه مشتری ها عقلشان به چشمشان است! و شما عاجز از نمایش کار خود. نرم ا�?زار انتزاعی ترین جزء تولید است.
3- نیازها کامل نیست. (Uncomplete Requirements) : اغلب موراد، پیش از ساخت واقعی نرم ا�?زار، همه نیازهای مشتری یا استخراج نشده و یا هنوز معلوم نیست. در پایان پروژه، تازه مشتری می �?همد که واقعا چه می خواهد.
4- �?نآوری به سرعت تغییر می کند (Technology Changes Rapidly): سرعت تغییرات در �?نآوری های ساخت نرم ا�?زار �?وق العاده سریع است. هر روز بستر و سیستم عامل جدید، هر روز تغییر سخت ا�?زار، تغییر زبانهای برنامه سازی و .... کدام �?نآوری را می شناسید که به این سرعت تغییر کند.
5-تجربه های مو�?ق بالغ نشده اند. (Immature Best Practices): به خاطر رشد سریع، اغلب تولید کنندگان به خوبی مهارت های تولید را کسب نکرده اند. معمولا در پروژه ها عوامل کی�?ی کمتر دیده می شود و بنابراین تجربه های مو�?ق کمتر بدست می آیند.حتی در صورت وجود، به دلیل تغییرات سریع �?نآوری، کمتر در پروژه های بعدی می توانند الگو باشند.
6- �?ناوری اطلاعات بسیار گسترده است. (Technology is a Vast Domain): در این که شک ندارید! کسی نیست در این زمینه که همه �?ن حری�? باشد (علامه دهر در نرم ا�?زار نداریم!) بنابراین کسی نمی تواند به تنهایی به همه قسمت های یک پروژه اشرا�? داشته باشد.
7-تجارب �?نآوری ناقص هستند. (Incomplete Technology Experience) : �?نآوری های جدید و نسخ های جدید ابزارها اغلب آنقدر با نسخه قبلیشان ت�?اوت دارد که به سرعت تجربه ا�?راد در این زمینه خارج از رده می شود. تجارب اکثر در موقع کار بدست آمده و بعد از آن کمتر به درد می خورند.
8- توسعه نرم ا�?زار اکتشا�?ی است. (Software Development is Research) : به دلیل عدم شناسایی نیازها و عدم دانش مشتریان نرم ا�?زار با آن، �?رآیند تولید اغلب ماهیت تحقیقاتی و یا اکتشا�?ی به خود می گیرد. ابزارها نیز جدیدند و توسعه دهنده باید آموزش است�?اده از آنها را کسب کند. بنابراین �?رآیند توسعه نرم ا�?زار �?قط ساخت آن نیست، یادگر�?تن آن است که با چه راهی می توان به نتیجه رسید.
9- کارهای تکراری خودکار هستند. (Automated Repetetive works) : در نرم ا�?زار و تولید آن، به حدی از خودکار سازی برای �?رآیند های تکراری رسیده ایم که در تولید های دیگر هنوز بحث آن هم مطرح نشده است، حجم بالای است�?اده مجدد (reuseability) از قطعات آماده، برون سپاری تولید (Outsourcing) و.... نمونه هایی از این خودکار سازی است.
10-ساختن در واقع طراحی است . (Construction is Actually Design) : همه �?رآیند های صنعتی مراحل مشخصی دارند (تحلیل، طراحی و اجرا : یک مدل خطی خوش تعری�?) اما نرم ا�?زار چنین نیست، در مرحله پیاده سازی و اجرا، نیازها به مرور تشخیص داده می شوند و این باعث می شود طراحی تا پایان ادامه پیدا کند. حتی در زمان نگهداری و پشتیبانی نیز، �?رآیند طراحی به شکل جدی مطرح است.
11- تغییرات راحت پنداشته می شوند. (Changes Considered easy) : تغییر نیاز در �?رآیند های تولید دیگر توسط مشتری بسیار سخت دیده می شود و وی سختی تغییر طراحی را در پایان پیاده سازی می �?همد و بنابراین آن را مطرح نمی کند و یا اگر مطرح کرد هزینه آن را می پذیرد. اما در نرم ا�?زار به خاطر ماهیت انتزاعی بودنش این تغییرات ساده �?رض می شوند. چون نرم ا�?زار به سادگی قابل توسعه است، مشتری متوجه نیست که چیزی که می خواهد واقعا چه هزینه ای برتولید کننده تحمیل می کند تا آن را اجرا کند. اغلب تغییرات ساختاری نیز بسیار ساده �?رض می شوند و تولید کننده را وادار به ساخت آن.
12- تغییرات اجتناب ناپذیرند. (Inevitable Changes) : ایا در نرم ا�?زار موقعیتی هست که تغییر نکند. همه چیز از �?نآوری تا نیاز مشتری تا تیم تولید تغییر می کند و این تغییرات بسیار سریع و غیر قابل اجتناب می باشند. گریزی نیست که آنها را در نظر بگیریم.به قولی تنها چیز "ثابت" در نرم ا�?زار خود م�?هوم "تغییر" است. هیچ نرم ا�?زاری در ابتدا کامل نیست و این تغییرات است که باعث می شود مطابق نیاز در بیاید.
این دوازده مورد و موارد دیگری از این دست، ت�?اوت های ماهوی و سختی و پرخطر بودن تولید نرم ا�?زار را نسبت به سایر تولید های صنعتی نشان می دهد. نتایج یک تحقیق که در سال 2000 انجام شده است نشان می دهد که تنها 28 درصد پروژه های نرم ا�?زاری مو�?ق بوده اند، 23درصد متوق�? شده اند و الباقی (یعنی 49%) با مشکلات جدی نظیر تاخیر تحویل، ا�?زایش بودجه و یا عدم برآورده کردن نیازها مواجه بوده اند.
این مشکل است، اما راه حل کجاست؟ طبیعی است در "مدیریت پروژه"! در آینده به بحث مدیریت پروژه به صورت جدی تری خواهم پرداخت.
همین!
در نوشتن این مطالب، کمک زیادی گر�?ته ام از کتاب "Software Project Secrets: Why Software Projects Fail" . گرچند هنوز کامل نخواندمش، خواندنش را به همه توصیه می کنم. مخصوصا کسانی که تجربه کار در پروژه های مختل�? را دارند و مسائل آن برایشان ملموس است.
George Stepanek, "Software Project Secrets: Why Software Projects Fail" , Apress, 2005
به �?رآيند صنعتي که دقت کنيد، مي بينيد که بعد از آنکه بشر به اين صرا�?ت ا�?تاد که خودش نمي تواند همه کار بکند و مثلا يک کلبه را به صورت کامل بسازد، ابتدا به صورت �?ردي و در مغازه ها و کارگاه هاي تخصصي کار شروع شد، آهنگري ها، نجاري ها یا در و پنجره سازي و .... و بعد ديد که نمي تواند با این روش برج بسازد، نمي تواند خودرو را در حجم انبوه توليد کند ، طرز �?کرش را عوض کرد و کارخانه ها را ساخت تا بتوانند در يک خط توليد به صورت انبوه، کالاي استاندارد توليد کنند و مشتري ها هم عادت کردند که خود را با کالا تطبيق دهند.
همين ات�?اق در نرم ا�?زار ا�?تاد، از جايي که به صورت اختصاصي براي هر مشتري پروژه توليد داشتيم، تا بسته هاي نرم ا�?زاري (Package) که به صورت انبوه توليد مي شد و �?روش مي ر�?ت و تا ERP که مي گوييم استاندارد است و هر مشتري خودش را تطبيق مي دهد و يا سيستم به صورت کم، تغيير داده مي شود تا نياز مشتري را �?راهم کند.اين توليد هم مانند توليد هاي ديگر نياز به تحليل، طراحي و پياده سازي دارد. مديريت پروژه مي خواهد توليدش و همان مسائل رادارد.
�?رآیند مدیریت پروژه (سازماندهی، برنامه ریزی و نظارت) به عنوان یک اصل جدانشدنی از هر پروژه ای در همه صنایع (منجمله نرم ا�?زار) هم وجود دارد.
اما نرم ا�?زار به لحاظ عوامل ماهیتیش چنان با بقیه کالاهای صنعتی مت�?اوت است که می بینیم در روشهای توسعه آن تنوع زیادی وجود دارد و هر روز یک مدل جدید برای توسعه نرم ا�?زار می بینیم. این ت�?اوت ها را به طور خلاصه می توانیم شامل موارد زیر بدانیم:
1- نرم ا�?زار پیچیده است (Complexity): به تعبیری "کاهش پیچیدگی قلب توسعه نرم ا�?زار است." یک برنامه کوچک گاهی هزاران خط �?رمان می شود و توسعه آن به هر نحو مشکل است. روشهایی مانند ماژول بندی و .... آمده است، اما هنوز هم پیچیدگی یکی از مهمترین اجزاء جدانشدنی نرم ا�?زار ها و �?رآیند تولید آن است.
2- نرم ا�?زار انتزاعی است (abstraction) : شما نمی توانید به شکل �?یزیکی آن را لمس کنید و نشان دهید. نه خودتان واقعا می توانید همه آن را یکجا در دست بگیرید و مشکلتر آنکه مشتری ها عقلشان به چشمشان است! و شما عاجز از نمایش کار خود. نرم ا�?زار انتزاعی ترین جزء تولید است.
3- نیازها کامل نیست. (Uncomplete Requirements) : اغلب موراد، پیش از ساخت واقعی نرم ا�?زار، همه نیازهای مشتری یا استخراج نشده و یا هنوز معلوم نیست. در پایان پروژه، تازه مشتری می �?همد که واقعا چه می خواهد.
4- �?نآوری به سرعت تغییر می کند (Technology Changes Rapidly): سرعت تغییرات در �?نآوری های ساخت نرم ا�?زار �?وق العاده سریع است. هر روز بستر و سیستم عامل جدید، هر روز تغییر سخت ا�?زار، تغییر زبانهای برنامه سازی و .... کدام �?نآوری را می شناسید که به این سرعت تغییر کند.
5-تجربه های مو�?ق بالغ نشده اند. (Immature Best Practices): به خاطر رشد سریع، اغلب تولید کنندگان به خوبی مهارت های تولید را کسب نکرده اند. معمولا در پروژه ها عوامل کی�?ی کمتر دیده می شود و بنابراین تجربه های مو�?ق کمتر بدست می آیند.حتی در صورت وجود، به دلیل تغییرات سریع �?نآوری، کمتر در پروژه های بعدی می توانند الگو باشند.
6- �?ناوری اطلاعات بسیار گسترده است. (Technology is a Vast Domain): در این که شک ندارید! کسی نیست در این زمینه که همه �?ن حری�? باشد (علامه دهر در نرم ا�?زار نداریم!) بنابراین کسی نمی تواند به تنهایی به همه قسمت های یک پروژه اشرا�? داشته باشد.
7-تجارب �?نآوری ناقص هستند. (Incomplete Technology Experience) : �?نآوری های جدید و نسخ های جدید ابزارها اغلب آنقدر با نسخه قبلیشان ت�?اوت دارد که به سرعت تجربه ا�?راد در این زمینه خارج از رده می شود. تجارب اکثر در موقع کار بدست آمده و بعد از آن کمتر به درد می خورند.
8- توسعه نرم ا�?زار اکتشا�?ی است. (Software Development is Research) : به دلیل عدم شناسایی نیازها و عدم دانش مشتریان نرم ا�?زار با آن، �?رآیند تولید اغلب ماهیت تحقیقاتی و یا اکتشا�?ی به خود می گیرد. ابزارها نیز جدیدند و توسعه دهنده باید آموزش است�?اده از آنها را کسب کند. بنابراین �?رآیند توسعه نرم ا�?زار �?قط ساخت آن نیست، یادگر�?تن آن است که با چه راهی می توان به نتیجه رسید.
9- کارهای تکراری خودکار هستند. (Automated Repetetive works) : در نرم ا�?زار و تولید آن، به حدی از خودکار سازی برای �?رآیند های تکراری رسیده ایم که در تولید های دیگر هنوز بحث آن هم مطرح نشده است، حجم بالای است�?اده مجدد (reuseability) از قطعات آماده، برون سپاری تولید (Outsourcing) و.... نمونه هایی از این خودکار سازی است.
10-ساختن در واقع طراحی است . (Construction is Actually Design) : همه �?رآیند های صنعتی مراحل مشخصی دارند (تحلیل، طراحی و اجرا : یک مدل خطی خوش تعری�?) اما نرم ا�?زار چنین نیست، در مرحله پیاده سازی و اجرا، نیازها به مرور تشخیص داده می شوند و این باعث می شود طراحی تا پایان ادامه پیدا کند. حتی در زمان نگهداری و پشتیبانی نیز، �?رآیند طراحی به شکل جدی مطرح است.
11- تغییرات راحت پنداشته می شوند. (Changes Considered easy) : تغییر نیاز در �?رآیند های تولید دیگر توسط مشتری بسیار سخت دیده می شود و وی سختی تغییر طراحی را در پایان پیاده سازی می �?همد و بنابراین آن را مطرح نمی کند و یا اگر مطرح کرد هزینه آن را می پذیرد. اما در نرم ا�?زار به خاطر ماهیت انتزاعی بودنش این تغییرات ساده �?رض می شوند. چون نرم ا�?زار به سادگی قابل توسعه است، مشتری متوجه نیست که چیزی که می خواهد واقعا چه هزینه ای برتولید کننده تحمیل می کند تا آن را اجرا کند. اغلب تغییرات ساختاری نیز بسیار ساده �?رض می شوند و تولید کننده را وادار به ساخت آن.
12- تغییرات اجتناب ناپذیرند. (Inevitable Changes) : ایا در نرم ا�?زار موقعیتی هست که تغییر نکند. همه چیز از �?نآوری تا نیاز مشتری تا تیم تولید تغییر می کند و این تغییرات بسیار سریع و غیر قابل اجتناب می باشند. گریزی نیست که آنها را در نظر بگیریم.به قولی تنها چیز "ثابت" در نرم ا�?زار خود م�?هوم "تغییر" است. هیچ نرم ا�?زاری در ابتدا کامل نیست و این تغییرات است که باعث می شود مطابق نیاز در بیاید.
این دوازده مورد و موارد دیگری از این دست، ت�?اوت های ماهوی و سختی و پرخطر بودن تولید نرم ا�?زار را نسبت به سایر تولید های صنعتی نشان می دهد. نتایج یک تحقیق که در سال 2000 انجام شده است نشان می دهد که تنها 28 درصد پروژه های نرم ا�?زاری مو�?ق بوده اند، 23درصد متوق�? شده اند و الباقی (یعنی 49%) با مشکلات جدی نظیر تاخیر تحویل، ا�?زایش بودجه و یا عدم برآورده کردن نیازها مواجه بوده اند.
این مشکل است، اما راه حل کجاست؟ طبیعی است در "مدیریت پروژه"! در آینده به بحث مدیریت پروژه به صورت جدی تری خواهم پرداخت.
همین!
در نوشتن این مطالب، کمک زیادی گر�?ته ام از کتاب "Software Project Secrets: Why Software Projects Fail" . گرچند هنوز کامل نخواندمش، خواندنش را به همه توصیه می کنم. مخصوصا کسانی که تجربه کار در پروژه های مختل�? را دارند و مسائل آن برایشان ملموس است.
George Stepanek, "Software Project Secrets: Why Software Projects Fail" , Apress, 2005