شکاف تکنولوژیک به تفاوت سطح دانش مشتری و مجری گفته می شود. به تعریف خودم: استفاده از تکنولوژی هایی که هنوز جدید هستند و به عرف استفاده در بازار تبدیل نشده اند.
به عنوان مثال در حال حاضر که استفاده از ویندوز 2003 به عنوان ویندوز سرورها مرسوم می باشد در صورتی که مجموعه ای از ویندوز سرور 2008 که به تازگی وارد بازار شده استفاده کند ، می تواند از این مورد استفاده مناسب کرده و هزینه بیشتری از مشتری دریافت کند و یا از آن به عنوان یک مزیت رقابتی در گرفتن پروژه (به قول معروف قاپ زدن پروژه از رقیب ها) استفاده کند.
بنابراین شکاف تکنولوژیک یکی از مواردی هست که از آن می توان به عنوان یک اهرم بازاریابی و یک مزیت رقابتی بهره جست.
به عنوان مثال شاید بتوان موارد زیر را در حال حاضر به عنوان یک شکاف تکنولوژیک به حساب آورد:
- استفاده از SQL Server 2008 (به جای نسخه های 2000 و یا 2005)
- استفاده از Visual Studio 2008 (به جای نسخه های 2000 و 2003)
- استفاده از Ajax
- استفاده از Windows 2008 (به جای نسخه های 2000 و یا 2003)
و....
متاسفانه برخلاف ذهنیت اکثر برنامه نویسان و مدیران IT، بیشینه کردن شکاف تکنولوژیک همیشه یک مزیت رقابتی نیست! بلکه ممکن است در مواردی به کاهش چشمگیر سوددهی یک تیم و یا حتی شکست یک پروژه نرم افزار تبدیل شود.
به نظر من تیم ها و یا برنامه نویسانی که هدف اصلی آنها انجام به موقع یک پروژه است و همچنین دارای رقیبان جدید نیستند تا حد امکان باید از تکنولوژی هایی استفاده کنند که دارای تجربه بیشتری در استفاده از آنها می باشند. به عنوان مثال فرض کنید یک شرکت تجاری سفارش تولید یک نرم افزار را به یک شرکت نرم افزار می دهد و Dead-line یک ماه برای فاز اولیه آن مشخص می کند. در این شرایط در صورتی که شرکت نرم افزاریی که به عنوان مثال از SQL Server 2000 و VS 2003 استفاده می کرده است بخواهد تحت فشار مشتری و رقابتی بازار از SQL Server 2008 و VS 2008 استفاده کند، قطعا یک ریسک بسیار خطرناک را به جان خریده است. به دلیل اینکه تیم نرم افزاری علاوه بر مشکل محدود بودن زمان اکنون باید با مشکل تجربه پیدا کردن با نسخه های جدید تکنولوژی نیست دست و پنجه نرم کند. شاید یک راه حل برای این مثال این باشد که مجری فاز اول را به موقع و با همان تکنولوژی هایی که مسلط است تحویل دهد و تبدیل به تکنولوژی جدید را در فازهای بعدی بگنجاند. اینگونه هم می توان مشتری را تا حدوده زیادی راضی نگاه داشت و هم یکی از ریسک های خطرناک را از بین برد.
یکی از چالش های پیش روی توسعه یک نرم افزار
اعتمادپذیری متقابل کارفرما و مجری
قسمت اول (دیدگاه کارفرما)
پیش نویس: در این نوشته منظور از نرم افزار، پروژهای نرم افزاری سطح کوچک تا متوسط (مثلا از بعد مالی سقف 50 میلیون تومان) می باشد.
با بررسی پروژهای نرم افزاری مشاهده می کنیم که متاسفانه بیش از 80 درصد این پروژه ها (در ایران به نظر من بیش از 90% این پروژه ها) در اولین تلاش به شکست منجر می شوند. و شاید 20% این پروژهای شکست خورده پس از تلاش و سرمایه گذاری مجدد و صرف زمان به موفقیت دست پیدا کنند. تعریفی که از موفقیت برای یه پروژه نرم افزار دارم رو خیلی خلاصه می گم: موفقیت در یک پروژه نرم افزاری یعنی:
1- نرم افزار به مرحله عملیاتی بودن برسد.
2- کارفرما و مجری هر دو از روند پروژه چه از نظر مادی چه معنوی رضایت داشته باشند.
3- پروژه حداقل یک سال تحت استفاده باقی بماند.
پروژه ای که یکی از این 3 شرط را نداشته باشد شکست خورده محسوب می شود.
در شروع مجدد کار روی یک پروژه شکست خورده شاید بتوان عامل عدم اعتماد را به عنوان اصلی ترین چالش پیش رو – چه برای کارفرما و چه برای مجری – به حساب آورد.
پروژه ای را در نظر بگیریم که مجری در اواسط پروژه از ادامه کار سرباز بزند (که به ده ها دلیل که موضوع این نوشته نیست این اتفاق رخ می دهد). در صورتی ادامه پروژه با یک مجری دیگر آن قدر ارزش داشته باشد که کارفرما تصمیم ادامه پروژه و واگذاری آن به مجری دیگری را بگیرد، مسئله عدم اعتماد و پیش گیری از اشتباهات گذشته به یکی از دغدغه های اصلی فکری کارفرما تبدیل خواهد شد و کارفرما به این نتیجه خواهد رسید که پارامتر و ملاک اول در انتخاب مجری اعتمادپذیری آن می باشد (نه سطح دانش بالای کارفرما). این اعتماد اولیه برای کارفرما چگونه به وجود خواهد آمد؟
بازبینی نحوه واگذاری پروژه به مجری معمولا به این نکته منتهی می شود که کارفرما معمولا تصمیم خود را بر اساس دیسیپلین ظاهری مجری و جلاسات اغوا گرایانه و توجیهی اولیه مجری – که معمولا مجری در آن سعی دارد جلسه را به مثال هایی از پروژهای انجام شده در ناسا و طرح ها و دیاگرام های پیچیده مزین کند – تصمیم خود را گرفته است و در این تصمیم گیری هیچ سوالی از درصد موفقیت پروژهای قبلی مجری نشده است. و مجری صرفا با لیست کردن اسم چند پروژه و نشان دادن چند Capture-Screen جلسه را به اتمام برده است.
در انتخاب مجری یکی از اصلی و مهترین عواملی از طرف کارفرما باید مد نظر گرفته شود درصد موفقیت پروژهای قبلی مجری است. به عنوان مثال کارفرما به مطرح کردن سوالات زیر می تواند به این موضوع نزدیک شود:
- * مجری تا کنون چند پروژه در این سطح را به انجام رسانده است؟ (توجه شود که انجام شدن پروژه همیشه با موفقیت آن برابر نیست)
- * چه تعدادی از پروژها به انتها رسیده و چه تعدادی شکست خورده اند؟
- * چه تعدادی از این پروژها تا هم اکنون توسط کارفرماهای قبلی در حال استفاده می باشند؟ پروژهایی که دیگر استفاده نمی شوند به چه دلایلی دیگر استفاده نمی شوند؟
- * دلایل شکست این پروژه با ذکر جزئیات چه بوده است؟ (بله! وقتی کارفرما در شرف یک سرمایه گذاری چند میلیون تومانی و یا شاید چند ده میلیون تومانی است، کاملا حق مطرح کردن این سوالات را دارد!)
- * تا چه زمانی بعد از اتمام، پروژه توسط کارفرماهای قبلی استفاده می شده است؟ زمان کمتر از یک سال منفی در نظر گرفته شود.
در قسمت دوم این نوشته عدم اعتماد از دیدگاه مجری رو خواهم نوشت.