« روزهايي که ايکاش نبودند | صفحه اصلی | زیرآب خودت را بزن! با اقتدار! با افتخار! ... البته با فکر! »
فروش قبل از تولید یا تولید قبل از فروش
&"August 4, 2008&"
در حرفه واسطه گری، گاهی وقت ها واسطه ها کارهایی را می کنند که انسان تعجب می کند، اینکه یک محصولی که هنوز تولید نشده را می خرند و می فروشند و سرآن معامله می کنند! همه ما ابتدا که چنین موضوعی را می شنویم بلند بلند می گوییم: از دست این دلال ها! ببین چقدر دروغ گو هستند!
اما به خودمان که می رسد، نرم افزاری را که آماده نشده را آنقدر طبیعی می فروشیم و یا در جلسه دمو در مورد آن صحبت می کنیم که بیایید ببینید که چقدر امکانات دارد! و به خودمان این مهلت را می دهیم که اگر مشتری خواست، اشکالی ندارد برایش تولید می کنیم! به قول بچه ها یک نوع خالی بندی با پشتوانه و خالی بندی بدون پشتوانه (اینکه اصلا می توانی آنکار را انجام دهی یا نمی توانی) تازه در این شرایط به خودمان هم دروغگو و شارلاتان هم نمی گوییم!
از شوخی که بگذریم، نگاهی بیاندازیم به مساله تولید و فروش نرم افزار:
حالت کلاسیک:
در شرکتهای Package ساز، روال آن بود که یک بسته نرم افزاری به صورت عمومی آماده می شد (فرآیند تولید) پس از وارسی در شرکت عرضه کننده ( Alfa Test) در چند مشتری اول تست بتا (Beta Test) را انجام داده و پس از انجام اصلاحات بدون اینکه دیگر به آن دستی زده شود تا نسخه بعدی همان سیستم به فروش می رفت. در هنگام فرآیند فروش هم تولید روی ایجاد نسخه های جدید و سرویس پک های بعدی نرم افزار کار می کرد. به عبارت ساده تر تولید قبل از فروش
در شرکت های پروژه محور، روال کار برعکس است، شرکت بر اساس توانمندی و یا سوابق قبلی یا هر پارامتر تعیین کننده دیگر، قراردادی را بایک شخص حقیقی و یا حقوقی منعقد کرده (فرآیند فروش) و پس از آن برای ایجاد آن نرم افزار مهلتی خواسته و تولیدی را آغاز می کنند تا محصول پروژه (Product) آماده شده و پس از طی مراحل مختلف به کارفرما تحویل و پروژه خاتمه یابد و پروژه بعدی آغاز شود، به عبارت ساده تر فروش قبل از تولید.
حالت امروزی:
اما در حالت نوین و شرکتهای امروزی، دیگر نمی شود به سادگی این تفکیک را انجام داد. نمی توان یک شرکت را Package ساز صرف و دیگر را پروژه محور خالص دانست. کسانی که پروژه کار می کنند به دلیل هزینه های بالایی تولید مایلند و به این چرخه وارد می شوند که محصول پروژه را به مشتری دیگری نیز بفروشند که همان سیاست Packe فروشی است. از سوی دیگر همانطور که قبلا در نوشته های دیگر به اشکال مختلف به آن اشاره کرده ام، هر مشتری حتی در شرکت Package ساز به دلیل نیاز به منطبق سازی (که در تجارت امروزی میان مشتریان یک امر طبیعی شمرده می شود و مشتری حاضر نیست نرم افزاری را بخرد که نتواند تغییر دهد) چیزهایی می خواهد که در اکثر مواقع یک فاز تولید را هر چند کوچک به سیستم تحمیل می کند. این مساله باعث می شود که در شرکتهای Package ساز در میان تیم تولید یک نوع سردرگمی و یا همان بحث تولید تحت فشار رخ دهد و میان اجرای پروژه های کوچک مختلف برای چند مشتری در یک زمان و تولید نسخه جدید اختلال ایجاد شود و از این مساله در مرحله اول تولید و در مرحله بعدی کل شرکت آسیب ببیند.
چرا؟
- اجرای چند پروژه با محدوده زمانی کم در یک زمان مدیریت پروژه متفاوتی از مدیریت یک پروژه بلند مدت دارد.
-این تولید چون پس از فروش همراه می شود، مشتری را پشت در سازمان می بیند، مشتری خواسته های عجیب و غریب مطرح می کند و به دلیل آنکه همه یا بخشی از پول را پرداخته است، توقع دارد که یکشبه دریافت کند که نمی شود.
-فرآیند توسعه و متدولوژی در پیش گرفته برای این نوع تولید با یک تولید کلاسیک متفاوت است، شاید در تولید یک بسته نرم افزاری بتوان فرآیند خطی، آبشاری و یا حتی توسعه تدریجی و یا مارپیچی را انتخاب نمود، اما به دلیل کمرنگ بودن و کند بودن ذاتی این فرآیند ها در ارتباط با مشتری برای منطبق سازی بسته نرم افزاری، باید به سراغ متدولوژی هایی با تعامل بالاتر مانند توسعه سریع نرم افزار (RAD) و یا روشهای چابک (Agile) مانند XP رفت.
- شتاب و تعدد این پروژه های کوچک، به تدریج تیم تولید را فرسوده می کند و تمرکز آنها از دست می رود بنابراین به تدریج بهره وری آنها در تولید پایین می یابد.
- به دلیل اینکه درآمد حاصل از منطبق سازی معمولا چندان بالا نیست، مدیران شرکتها و مدیران مالی اهمیت زیادی برای آنها قائل نیستند و این بی انگیزگی به واحد تولید نیز منتقل می شود.
-...
اما برای رفع این مشکل چه باید کرد:
- نیازسنجی درست: در چقدر بتوان قبل از فروش، نیاز مشتری را حدس زد و برای آن راه حل پیدا کرد، می توان از حجم منطبق سازی کاست، اگر چه این قضیه صددرصد اتفاق نمی افتد.
- تولید محصول با قابلیت منطبق سازی بالا: هر چقدر بتوان در عین سادگی، محصولی را تولید کرد که خود مشتری بتواند برخی نیازهایش را پاسخ دهد و برای خود تغییرات را ایجاد کند و یا نهایتا در واحد پشتیبانی این تغییرات بدون نیاز به برنامه نویسی صورت گیرد، فشار از روی تیم تولید برداشته می شود.
-تقسیم تیم تولید به دو گروه: گروهی از این تیم در یک کار روزانه ("برنامه نویسان روزکار" یادتان هست) بدون استرس و به دور از کار عجله ای عهده دار تولید نسخه جدید و یا محصول جدید بنمایند و گروهی دیگر را که توانایی کار فشرده و با وقت بیشتر را دارند را به صورت مجزا (حتی از جنبه فیزیکی نیز مجزا) عهده دار مسؤولیت منطبق سازی نمایند.
- تولید کننده قید حضور در بازار رقابتی را بزند و کار دیگری بکند و یا از اهرم های فشار پول و پارتی(!) برای حضور در بازار استفاده کند!
همین!