Y@SiN
11-19-2009, 07:03 PM
در حر�?ه واسطه گری، گاهی وقت ها واسطه ها کارهایی را می کنند که انسان تعجب می کند، اینکه یک محصولی که هنوز تولید نشده را می خرند و می �?روشند و سرآن معامله می کنند! همه ما ابتدا که چنین موضوعی را می شنویم بلند بلند می گوییم: از دست این دلال ها! ببین چقدر دروغ گو هستند!
اما به خودمان که می رسد، نرم ا�?زاری را که آماده نشده را آنقدر طبیعی می �?روشیم و یا در جلسه دمو در مورد آن صحبت می کنیم که بیایید ببینید که چقدر امکانات دارد! و به خودمان این مهلت را می دهیم که اگر مشتری خواست، اشکالی ندارد برایش تولید می کنیم! به قول بچه ها یک نوع خالی بندی با پشتوانه و خالی بندی بدون پشتوانه (اینکه اصلا می توانی آنکار را انجام دهی یا نمی توانی) تازه در این شرایط به خودمان هم دروغگو و شارلاتان هم نمی گوییم!
از شوخی که بگذریم، نگاهی بیاندازیم به مساله تولید و �?روش نرم ا�?زار:
حالت کلاسیک:
در شرکتهای Package ساز، روال آن بود که یک بسته نرم ا�?زاری به صورت عمومی آماده می شد (�?رآیند تولید) پس از وارسی در شرکت عرضه کننده ( Alfa Test) در چند مشتری اول تست بتا (Beta Test) را انجام داده و پس از انجام اصلاحات بدون اینکه دیگر به آن دستی زده شود تا نسخه بعدی همان سیستم به �?روش می ر�?ت. در هنگام �?رآیند �?روش هم تولید روی ایجاد نسخه های جدید و سرویس پک های بعدی نرم ا�?زار کار می کرد. به عبارت ساده تر تولید قبل از �?روش
در شرکت های پروژه محور، روال کار برعکس است، شرکت بر اساس توانمندی و یا سوابق قبلی یا هر پارامتر تعیین کننده دیگر، قراردادی را بایک شخص حقیقی و یا حقوقی منعقد کرده (�?رآیند �?روش) و پس از آن برای ایجاد آن نرم ا�?زار مهلتی خواسته و تولیدی را آغاز می کنند تا محصول پروژه (Product) آماده شده و پس از طی مراحل مختل�? به کار�?رما تحویل و پروژه خاتمه یابد و پروژه بعدی آغاز شود، به عبارت ساده تر �?روش قبل از تولید.
حالت امروزی:
اما در حالت نوین و شرکتهای امروزی، دیگر نمی شود به سادگی این ت�?کیک را انجام داد. نمی توان یک شرکت را Package ساز صر�? و دیگر را پروژه محور خالص دانست. کسانی که پروژه کار می کنند به دلیل هزینه های بالایی تولید مایلند و به این چرخه وارد می شوند که محصول پروژه را به مشتری دیگری نیز ب�?روشند که همان سیاست Packe �?روشی است. از سوی دیگر همانطور که قبلا در نوشته های دیگر به اشکال مختل�? به آن اشاره کرده ام، هر مشتری حتی در شرکت Package ساز به دلیل نیاز به منطبق سازی (که در تجارت امروزی میان مشتریان یک امر طبیعی شمرده می شود و مشتری حاضر نیست نرم ا�?زاری را بخرد که نتواند تغییر دهد) چیزهایی می خواهد که در اکثر مواقع یک �?از تولید را هر چند کوچک به سیستم تحمیل می کند. این مساله باعث می شود که در شرکتهای Package ساز در میان تیم تولید یک نوع سردرگمی و یا همان بحث تولید تحت �?شار رخ دهد و میان اجرای پروژه های کوچک مختل�? برای چند مشتری در یک زمان و تولید نسخه جدید اختلال ایجاد شود و از این مساله در مرحله اول تولید و در مرحله بعدی کل شرکت آسیب ببیند.
چرا؟
- اجرای چند پروژه با محدوده زمانی کم در یک زمان مدیریت پروژه مت�?اوتی از مدیریت یک پروژه بلند مدت دارد.
-این تولید چون پس از �?روش همراه می شود، مشتری را پشت در سازمان می بیند، مشتری خواسته های عجیب و غریب مطرح می کند و به دلیل آنکه همه یا بخشی از پول را پرداخته است، توقع دارد که یکشبه دریا�?ت کند که نمی شود.
-�?رآیند توسعه و متدولوژی در پیش گر�?ته برای این نوع تولید با یک تولید کلاسیک مت�?اوت است، شاید در تولید یک بسته نرم ا�?زاری بتوان �?رآیند خطی، آبشاری و یا حتی توسعه تدریجی و یا مارپیچی را انتخاب نمود، اما به دلیل کمرنگ بودن و کند بودن ذاتی این �?رآیند ها در ارتباط با مشتری برای منطبق سازی بسته نرم ا�?زاری، باید به سراغ متدولوژی هایی با تعامل بالاتر مانند توسعه سریع نرم ا�?زار (RAD) و یا روشهای چابک (Agile) مانند XP ر�?ت.
- شتاب و تعدد این پروژه های کوچک، به تدریج تیم تولید را �?رسوده می کند و تمرکز آنها از دست می رود بنابراین به تدریج بهره وری آنها در تولید پایین می یابد.
- به دلیل اینکه درآمد حاصل از منطبق سازی معمولا چندان بالا نیست، مدیران شرکتها و مدیران مالی اهمیت زیادی برای آنها قائل نیستند و این بی انگیزگی به واحد تولید نیز منتقل می شود.
-...
اما برای ر�?ع این مشکل چه باید کرد:
- نیازسنجی درست: در چقدر بتوان قبل از �?روش، نیاز مشتری را حدس زد و برای آن راه حل پیدا کرد، می توان از حجم منطبق سازی کاست، اگر چه این قضیه صددرصد ات�?اق نمی ا�?تد.
- تولید محصول با قابلیت منطبق سازی بالا: هر چقدر بتوان در عین سادگی، محصولی را تولید کرد که خود مشتری بتواند برخی نیازهایش را پاسخ دهد و برای خود تغییرات را ایجاد کند و یا نهایتا در واحد پشتیبانی این تغییرات بدون نیاز به برنامه نویسی صورت گیرد، �?شار از روی تیم تولید برداشته می شود.
-تقسیم تیم تولید به دو گروه: گروهی از این تیم در یک کار روزانه ("برنامه نویسان روزکار" یادتان هست) بدون استرس و به دور از کار عجله ای عهده دار تولید نسخه جدید و یا محصول جدید بنمایند و گروهی دیگر را که توانایی کار �?شرده و با وقت بیشتر را دارند را به صورت مجزا (حتی از جنبه �?یزیکی نیز مجزا) عهده دار مسؤولیت منطبق سازی نمایند.
- تولید کننده قید حضور در بازار رقابتی را بزند و کار دیگری بکند و یا از اهرم های �?شار پول و پارتی(!) برای حضور در بازار است�?اده کند!
همین!
اما به خودمان که می رسد، نرم ا�?زاری را که آماده نشده را آنقدر طبیعی می �?روشیم و یا در جلسه دمو در مورد آن صحبت می کنیم که بیایید ببینید که چقدر امکانات دارد! و به خودمان این مهلت را می دهیم که اگر مشتری خواست، اشکالی ندارد برایش تولید می کنیم! به قول بچه ها یک نوع خالی بندی با پشتوانه و خالی بندی بدون پشتوانه (اینکه اصلا می توانی آنکار را انجام دهی یا نمی توانی) تازه در این شرایط به خودمان هم دروغگو و شارلاتان هم نمی گوییم!
از شوخی که بگذریم، نگاهی بیاندازیم به مساله تولید و �?روش نرم ا�?زار:
حالت کلاسیک:
در شرکتهای Package ساز، روال آن بود که یک بسته نرم ا�?زاری به صورت عمومی آماده می شد (�?رآیند تولید) پس از وارسی در شرکت عرضه کننده ( Alfa Test) در چند مشتری اول تست بتا (Beta Test) را انجام داده و پس از انجام اصلاحات بدون اینکه دیگر به آن دستی زده شود تا نسخه بعدی همان سیستم به �?روش می ر�?ت. در هنگام �?رآیند �?روش هم تولید روی ایجاد نسخه های جدید و سرویس پک های بعدی نرم ا�?زار کار می کرد. به عبارت ساده تر تولید قبل از �?روش
در شرکت های پروژه محور، روال کار برعکس است، شرکت بر اساس توانمندی و یا سوابق قبلی یا هر پارامتر تعیین کننده دیگر، قراردادی را بایک شخص حقیقی و یا حقوقی منعقد کرده (�?رآیند �?روش) و پس از آن برای ایجاد آن نرم ا�?زار مهلتی خواسته و تولیدی را آغاز می کنند تا محصول پروژه (Product) آماده شده و پس از طی مراحل مختل�? به کار�?رما تحویل و پروژه خاتمه یابد و پروژه بعدی آغاز شود، به عبارت ساده تر �?روش قبل از تولید.
حالت امروزی:
اما در حالت نوین و شرکتهای امروزی، دیگر نمی شود به سادگی این ت�?کیک را انجام داد. نمی توان یک شرکت را Package ساز صر�? و دیگر را پروژه محور خالص دانست. کسانی که پروژه کار می کنند به دلیل هزینه های بالایی تولید مایلند و به این چرخه وارد می شوند که محصول پروژه را به مشتری دیگری نیز ب�?روشند که همان سیاست Packe �?روشی است. از سوی دیگر همانطور که قبلا در نوشته های دیگر به اشکال مختل�? به آن اشاره کرده ام، هر مشتری حتی در شرکت Package ساز به دلیل نیاز به منطبق سازی (که در تجارت امروزی میان مشتریان یک امر طبیعی شمرده می شود و مشتری حاضر نیست نرم ا�?زاری را بخرد که نتواند تغییر دهد) چیزهایی می خواهد که در اکثر مواقع یک �?از تولید را هر چند کوچک به سیستم تحمیل می کند. این مساله باعث می شود که در شرکتهای Package ساز در میان تیم تولید یک نوع سردرگمی و یا همان بحث تولید تحت �?شار رخ دهد و میان اجرای پروژه های کوچک مختل�? برای چند مشتری در یک زمان و تولید نسخه جدید اختلال ایجاد شود و از این مساله در مرحله اول تولید و در مرحله بعدی کل شرکت آسیب ببیند.
چرا؟
- اجرای چند پروژه با محدوده زمانی کم در یک زمان مدیریت پروژه مت�?اوتی از مدیریت یک پروژه بلند مدت دارد.
-این تولید چون پس از �?روش همراه می شود، مشتری را پشت در سازمان می بیند، مشتری خواسته های عجیب و غریب مطرح می کند و به دلیل آنکه همه یا بخشی از پول را پرداخته است، توقع دارد که یکشبه دریا�?ت کند که نمی شود.
-�?رآیند توسعه و متدولوژی در پیش گر�?ته برای این نوع تولید با یک تولید کلاسیک مت�?اوت است، شاید در تولید یک بسته نرم ا�?زاری بتوان �?رآیند خطی، آبشاری و یا حتی توسعه تدریجی و یا مارپیچی را انتخاب نمود، اما به دلیل کمرنگ بودن و کند بودن ذاتی این �?رآیند ها در ارتباط با مشتری برای منطبق سازی بسته نرم ا�?زاری، باید به سراغ متدولوژی هایی با تعامل بالاتر مانند توسعه سریع نرم ا�?زار (RAD) و یا روشهای چابک (Agile) مانند XP ر�?ت.
- شتاب و تعدد این پروژه های کوچک، به تدریج تیم تولید را �?رسوده می کند و تمرکز آنها از دست می رود بنابراین به تدریج بهره وری آنها در تولید پایین می یابد.
- به دلیل اینکه درآمد حاصل از منطبق سازی معمولا چندان بالا نیست، مدیران شرکتها و مدیران مالی اهمیت زیادی برای آنها قائل نیستند و این بی انگیزگی به واحد تولید نیز منتقل می شود.
-...
اما برای ر�?ع این مشکل چه باید کرد:
- نیازسنجی درست: در چقدر بتوان قبل از �?روش، نیاز مشتری را حدس زد و برای آن راه حل پیدا کرد، می توان از حجم منطبق سازی کاست، اگر چه این قضیه صددرصد ات�?اق نمی ا�?تد.
- تولید محصول با قابلیت منطبق سازی بالا: هر چقدر بتوان در عین سادگی، محصولی را تولید کرد که خود مشتری بتواند برخی نیازهایش را پاسخ دهد و برای خود تغییرات را ایجاد کند و یا نهایتا در واحد پشتیبانی این تغییرات بدون نیاز به برنامه نویسی صورت گیرد، �?شار از روی تیم تولید برداشته می شود.
-تقسیم تیم تولید به دو گروه: گروهی از این تیم در یک کار روزانه ("برنامه نویسان روزکار" یادتان هست) بدون استرس و به دور از کار عجله ای عهده دار تولید نسخه جدید و یا محصول جدید بنمایند و گروهی دیگر را که توانایی کار �?شرده و با وقت بیشتر را دارند را به صورت مجزا (حتی از جنبه �?یزیکی نیز مجزا) عهده دار مسؤولیت منطبق سازی نمایند.
- تولید کننده قید حضور در بازار رقابتی را بزند و کار دیگری بکند و یا از اهرم های �?شار پول و پارتی(!) برای حضور در بازار است�?اده کند!
همین!