خانه / فنّاوري‌اطلاعات / حکایاتی از قراردادهای فناوری اطلاعات . بخش اول

حکایاتی از قراردادهای فناوری اطلاعات . بخش اول

مدتی پیش در صفحه شخصی‌ام از بدعهدی کارفرمایان دولتی نوشته بودم که یکی از دوستان خوبم یادآوری کردند که حال چه می‌توان کرد؟

سوال خوبی بود … و به همین بهانه بعضی نکات را در خصوص عقد قراردادهای فناوری اطلاعات، بعنوان پیشنهاد عرض می‌کنم و امیدوارم که دوستان عزیزم با تجارب خود کمک کنند تا این پست برای علاقمندان بیشتر مفید واقع گردد.

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

توضیح واجب: تجربیات و نکاتی که  در ادامه نوشته می‌شود برای شرکت‌های زیر صدق نمی‌کند.

الف) شرکت‌هایی که پارتی‌های کت و کلفت دارند و اصولا چه پروژه را تحویل بدهند و چه تحویل ندهند صورت وضعیت ایشان پاس می‌شود. حال این پارتی کت و کلفت می‌تواند یک سهام‌دار از شرکت باشد که همزمان معاون یا مشاور یا رئیس یا …سازمان کارفرما هم هست و یا می‌تواند شریک همین قرارداد جاری باشد … مثلا قرارشده که ۵۰% یا ۳۰% (چون پائین‌تر از ۳۰% ندیدم ذکر نکردم!) از هر پرداخت را دریافت نماید.

ب) شرکت‌هایی که تعداد زیادی نیرو استخدام کرده‌اند و دلشان نمی‌آید (یا به هر دلیل دیگری نمی‌توانند) به همکاری با ایشان خاتمه دهند و در نتیجه باید به هر قیمتی شده پروژه‌ای داشته باشند و (حتی به ضرر) شرکت را زنده نگاه‌دارند.

ج) پیمانکاران انحصاری شرکت‌ها یا سازمان‌های دولتی که به نحوی خدمتی را بصورتی انحصاری در اختیار گرفته‌اند و با تغییر رئیس و مدیر کل و معاون و وزیر و رئیس جمهور تغییر نمی‌کنند.

لذا نکات و تجربیاتی که در ادامه خواهید دید، صرفا درباره شرکت‌هایی مورد استفاده خواهد داشت که جزء سه دسته فوق نباشند.

توضیح مستحب: این نکات و تجربیات بیشتر برای دوستان جوان‌ترم و عزیزانی که به تازگی (مثلا کمتر از ۱۰ سال تجربه حضور در بازار فناوری اطلاعات) وارد این بازار شده‌اند کاربرد داشته و عزیزانی که سالهاست در این عرصه مشغول به فعالیت هستند، شاید از خواندن این نکات احساس خستگی نموده و یا خاطراتی برای ایشان زنده شود :-) که پیشاپیش از ایشان پوزش طلبیده و حقیقتا نمی‌خواهم وقت ایشان را بگیرم. همچنین تمام موضوعاتی که در ادامه خواهم نوشت، کاملا واقعی بوده و تمام پیشنهاداتی که ارائه می‌شود در سازمان‌های دولتی و خصوصی انجام پذیرفته است. لذا امکان‌پذیر است …

باری … و اما تجربیات و نکات مورد نظر در قراردادهای فناوری اطلاعات …

قدم اول: محصول پروژه را خیلی دقیق توصیف کنید.

مهم‌ترین نکته از نظر من تعریف دقیق محصول قرارداد یا پروژه است. دوستانی که از Scrum بعنوان روش همکاری تیمی و پیشبرد پروژه استفاده می‌کنند در این زمینه با عبارت DoD (یا Definition of Done) آشنا هستند. به خاطر دارم که در یکی از سازمان‌های دولتی پروژه‌ای داشتم که با یک خط نوشته روی کاغذ شروع شد و فی‌المجلس در حضور کارفرما زمان‌بندی و برآورد بودجه کردیم و آنچه برای شروع پروژه نیاز داشتیم اعلام شد و چند روز بعد پروژه شروع شد … موضوع Replication اطلاعات بین چند سرور Oracle در سراسر کشور بود که من و دوست صمیمی و عزیزم سهیل معتمد رستگار از روز دوم عید نوروز به بعد مشغول اجرای پروژه بودیم … اما دلیل اصلی تمام‌نشدن پروژه (و طبیعتا تسویه حساب نشدن آن تا امروز) این بود که نیازمندی‌های پروژه تقریبا هر یکی دو روز در جلسه هماهنگی عوض می‌شد تا جایی که من و سهیل از کارفرما تعریفی مکتوب و دقیق از نیازمندی‌های پروژه خواستیم … که ندادند و پروژه در همان وضعیت باقی‌ماند تا پیمانکار مفت کارکننده بعدی آمد و بخش دیگری را انجام داد و زمانی که او نیازمندی‌های پروژه را درخواست کرد کار از او گرفته شد و در همان وضعیت باقی‌ماند تا پیمانکار …

برای تعریف دقیق نیازمندی‌های پروژه کافیست کارفرما پاسخ این سوال را با جزئیات کافی ارائه کند:

“در صورتی که چه محصولی را با چه مشخصاتی به شما بدهم، حاضرید با من بصورت کامل تسویه حساب کنید؟”

این نیازمندی‌ها بایستی حتما شامل نیازمندی‌های کارکردی (Functional requirements) و نیازمندی‌های غیرکارکردی (Non-Function requirements) بوده و با جزئیات کافی نوشته شده باشند تا امکان برآورد زمان انجام کار با دقتی در حد روز میسر گردد.  تنها در این صورت است که ماهیت محصول نهایی پروژه و شرائط تحویل آن کاملا برای دو طرف مشخص بوده و قابلیت توافق بر روی آن وجود خواهد داشت.

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

۱) یک فاز تحلیل نیازمندی‌ها یا مطالعه اولیه برای تدوین دفترچه توصیف محصول پروژه اصلی در نظر بگیرید و در آن تمامی نکات مورد نظر طراح و نیازمندی‌های کارفرما یا مالک محصول را قید کنید. آنگاه این دفترچه را برای توصیف دقیق محصول و در نتیجه برآورد زمان و بودجه پروژه اصلی بکارگیرید.

۲) در نظر داشته باشید هر پروژه‌ای را می‌توان تا اندازه‌ای بهبود بخشید. پس با کارفرما قرار بگذارید همه محتویات دفترچه فوق‌الذکر تنها و تنها فاز یک پروژه بوده و هر امکان و قابلیتی بجز آنچه در این دفترچه قید شده مربوط به فازهای بعدی است که انشاءالله پس از استقرار کامل فاز اول در سند مدیریت تغییرات نوشته شده و جداگانه مورد برآورد زمان و بودجه قرارخواهد گرفت. لذا تنها تعهد شما در حال حاضر تحویل محصول یا محصولات مذکور در این دفترچه با شرائط قید شده در آن است.

حکایاتی از قراردادهای فناوری اطلاعات . بخش دوم »



درباره ی عليرضا صائبي

فعلا در حوزه فناوری اطلاعات به مشاوره مشغولم …
کار در حوزه Business intelligence و بخصوص Text processing و SNA را دوست دارم … احساس می‌کنم در این دو پردازش می‌توانم واقعیت‌های زیادی را ببینم …

همچنین ببینید

کارگاه آموزشی استقرار ITIL در سازمان . ITSM

کارگاه آموزشی استقرار ITIL در سازمان ( ITSM ) پنج‌شنبه‌ها از ۲۳ شهریورماه ۱۳۹۶ به ...

۴ دیدگاه

  1. سلام فرامرز جان …
    آره واقعا … :)

  2. فرامرز ذبیحیان

    درود بر استاد گرامی

    خاطرات جوانی زنده شد. از قدیم گفته اند که : خوش بود گر محک تجربه آید به میان …

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

  4. سلام و احترام
    خدمت مهندس صائبی
    مهندس اگر ممکنه تشکیل گروه بدهیم در واتس آپ
    با سپاس