وب سایت علیرضا صائبی وبلاگ علیرضا صائبی
« حکایاتی از قراردادهای فناوری اطلاعات . بخش پنجم
قدم پنجم: تمام توجه خود را معطوف به تولید محصول نهایی توافق‌شده کنید.
کار اضافی انجام ندهید. فقط کاری را انجام دهید که هر روز شما را یک قدم به محصول نهایی توافق‌شده پروژه نزدیک‌تر نماید. بعضی از ما مهندسیم و دوست داریم در میانه کار تحقیقات فنی خود را نیز کامل کنیم. این کار خوب و مستحب است ولی تحویل محصول پروژه‌ای که به انجام آن متعهد شدید واجب است. بنابراین توصیه می‌کنم یک پروژه را بگیرید و شروع کنید و به انتها برسانید و تحویل دهید، آنگاه پروژه بعدی. طبیعی است که اگر شما در شرکت خود ۴ تیم دارید حداکثر توان انجام ۴ پروژه را بصورت موازی خواهید داشت نه ۱۶ پروژه! … در واقع عرض من ناظر به اصلی است به نام: “هر نفر در هر زمان فقط یک کار” که معتقدم می‌تواند پیشرفت یک پروژه را تضمین کند. از اشتباهات مرسوم مدیران واحدها، شرکت‌ها یا تیم‌ها به نظر من آنست‌که برای شروع کار جدید زمان‌بندی خاصی را در نظر ندارند و هر کاری که پیشنهاد یا درخواست شد را شروع می‌کنند. به همین علت پیشنهاد می‌کنم یک پروژه را به سرانجام برسانید و سپس به پروژه بعدی متعهد شوید. در این زمینه از اثر کارهای باقیمانده بر کاهش راندمان فردی (اثر زیگارنیک) غافل نشوید.
لذا چنانچه در قدم دو و نیم، برنامه‌ریزی مناسبی برای پروژه انجام داده باشید، همکاران و اعضاء تیم پروژه هر روز برنامه روزانه خود را می‌دانند و منتظر ابلاغ کاری از سوی مدیر پروژه نخواهند بود. از سوی دیگر اگر مبنا را میزان کار باقیمانده قراردهید و از ابزارهای ساده مدیریت پروژه (نظیر پیرنگ) بصورت مستمر استفاده کنید، (با توجه به این که همیشه حجم کار باقیمانده را مقابل چشم خود دارید) بصورت خودکار توجه شما همواره معطوف به پیشبرد پروژه خواهد بود و خود را سرگرم اموری که پروژه را یک قدم به پیش نمی‌برد، نخواهید نمود. توجه کنید، در جلسات و ارتباطات مختلفی که برای ارزیابی پیشرفت کار دارید، مهم آنست‌که چه میزان از محصول پروژه “تمام” شده است، نه اینکه من یا دیگر همکارم در هفته گذشته چه کرده‌ایم. بد نیست ذکر کنم، از نظر من کار تمام شده کاری است که نماینده کارفرما (یا ناظر پروژه) آن را تحویل گرفته، تائید کرده و حاضر است مبلغ مربوط به آن بخش را در وجه پیمانکار تسویه نماید و در غیر اینصورت هنوز کار تمام نشده و صرفا بخش‌هایی از آن انجام شده است. توصیه می‌کنم در این قدم بسیار سخت‌گیر باشید و در طول مدت انجام پروژه هیچ کاری بجز حرکت در مسیر تحویل تعهدات پروژه (که در بخش اول به نام DoD از آن یاد کردم) انجام ندهید.
در بعضی از انواع پروژه مانند پروژه‌های تحقیقاتی یا مطالعاتی و یا فاز طراحی پروژه‌های نرم‌افزاری، برنامه‌ریزی پروژه کمی متفاوت بوده و معطوف به تکمیل سند طراحی نرم‌افزار یا سامانه موضوع قرارداد می‌شود. در واقع در این نوع قراردادها محصول شما یک طرح نرم‌افزاری همراه با تعدادی فایل ارائه یا Presentation خواهد بود. در این حالت پیشنهاد می‌کنم حتما در ابتدای کار طی جلسه‌ای فرمتهای خروجی و یا قالب تحویل محصول را با تمام جزئیات از کارفرما یا نماینده فنی وی دریافت کنید (حتی قبل از برآورد قیمت و در زمان عقد قرارداد) و آنگاه نسبت به برنامه‌ریزی پروژه اقدام کنید. در واقع در این نوع پروژه‌ها مهم آنست که درک متقابل و مورد توافق شما و مدیر پروژه کارفرما از محصول فاز طراحی یا پروژه تحقیقاتی چیست؟ اجازه دهید مثالی عرض کنم … سال ۱۳۷۸ پروژه‌ای در دست اجرا داشتم که فاز طراحی آن شامل طراحی ۱۰ سیستم با حدود ۲۰۰ فرایند متوسط بود. محیط ارائه مستندات طراحی نیز Oracle Designer اعلام شده و متدولوژی پیشبرد پروژه نیز اقتباسی از Oracle case*method در نظر گرفته شده بود. من و دوستانم سه ماه روی طراحی پروژه کارکردیم و پس از تحویل همه مستندات، نماینده فنی کارفرما گفت: “شما چرا همه مستندات را در Oracle designer و بصورت الکترونیکی تهیه کردید؟ … مستندات کاغذی هم لازم است!” … طبیعتا من و همکارانم (که در آن زمان فکر می‌کردیم نماینده فنی کارفرما یا ناظر فرستاده مستقیم و تام‌الاختیار خداوند متعال بر روی زمین هستند و فرمایشات ایشان وحی مُنزَل است و اصولا امکان ندارد که تجربه کافی نداشته باشند و چیزی را بلد نباشند و هوس بر ایشان غالب نگشته و معصوم از اشتباه هستند!!) بنا به صورت جلسه نوشته شده شروع به ساخت مستندات کاغذی کردیم … این روال سه ماه دیگر به طول انجامید و نماینده فنی مربوطه از بس دقیق بود طی سه ماه آینده همه اشکالات ما در فونت‌ها، فاصله خطوط، Opacity خط جداول ماتریس‌ها، اشکالات ویرایش گزارشات مکتوب و خیلی موارد دیگر را رفع!! کرد. البته در این زمان فقط یک نفر از تیم روی مستندسازی کار می‌کرد و دیگران به برنامه‌سازی مشغول بودند، اما بهرحال من و دوستانم کماکان تا امسال ۲۵% وجه مربوط به فاز طراحی را دریافت نکردیم چون هنوز اشکالاتی در مستندات وجود داشت که واقعا برای تیم پروژه قابل درک نبود و کارفرما آن مبلغ ۲۵% را تا رفع آن اشکالات پرداخت نکرد! … متن آخرین اشکال گرفته شده بر اساس هشتمین صورتجلسه تحویل مستندات طراحی این بود: “پیمانکار تعیین نکرده است که کدام یک از کارکردهای سیستم Immediate و کدام یک Overnight انجام می‌شود!” که در این زمان اعضاء تیم جامه‌دران و فریادکنان سر به بیابان همی گذاردند و …
پر واضح است که کارفرما بایستی در ابتدای کار تمامی قالب‌ها و جزئیات شرائط تحویل محصول را بصورت مکتوب ارائه نماید و اگر چنین اسنادی موجود نیست، طی یک صورتجلسه فرمتهای مورد نظر خود را با پیمانکار توافق کند و اگر خیلی دقیق است و پروژه بزرگ است و ارزش دارد می‌تواند تهیه این قالب‌ها را به عنوان یک فاز از کار در قالب یک پروژه مطالعاتی مطرح نموده و به انجام رسانده و خلقی را از نگرانی و نارضایتی برهاند. خارج از شوخی با تهیه و مشخص بودن این اسناد شما بعنوان پیمانکار بایستی تمام سعی خود را صرف تکمیل آن اسناد (نه کمتر نه بیشتر و نه هیچ کار دیگر) نمایید. چنانچه اسناد از نظر شما نقصی دارند و یا امکان بهبود آن‌ها وجود دارد، پیشنهاد می‌کنم اول اسناد را تکمیل و تحویل و تسویه حساب نموده و آنگاه پیشنهادات خود را در اختیار کارفرما قراردهید. در این شرائط اگر کارفرما تمایل به تکمیل آن اسناد در قالب پیشنهادات شما داشته باشد، می‌تواند از بند تغییر مقادیر کار استفاده نموده و به شما سفارشی اضافه بر شرح خدمات عادی قرارداد بدهد که طبیعتا نیازمند تسویه حساب جداگانه خواهد بود.
اگر حقیقتا این رویکرد را در طی یک پروژه در پیش بگیرید، تمام سعی شده معطوف به تحویل محصولی که با مشتری توافق کردید خواهد گردید و در نتیجه هم تحویل محصول در مدت زمان مناسب‌تری انجام شده و هم منافع مالی مورد نظر شما از پروژه در مواقع مناسبی تامین خواهد شد.
یه یاد دارم در یکی از پروژه‌ها که قراربود یک نرم‌افزار مبتنی بر نقشه بسازیم، حداقل ۳ مرتبه کل تکنولوژی مورد استفاده در نرم‌افزار را از پایه بازنویسی کردیم. در طی این دوران نه تنها محصولی تحویل ندادیم، بلکه متهم به تاخیر و سهل‌انگاری در پیشبرد کار شدیم … در حالی که من و دوستانم واقعا سعی می‌کردیم بهترین محصول را ارائه کنیم. این ایده‌آل گرایی بود که تحویل محصول ما را به تاخیر انداخته بود. در این زمینه اصطلاحی هست به نام Time to Market … یعنی زمان رسیدن محصول به بازار … واقعا اگر محصول در زمانی که کارفرمای شما انتظار آن را دارد به دست او نرسد شاید موضوعیت خود را از دست داده و دیگر به کار نیاید. لذا واقعا برقراری تعادل بین کیفیت محصول و زمان رسیدن آن به دست مشتری (کارفرما) از هنرهای مدیر و اعضاء تیم پروژه است.
حکایاتی از قراردادهای فناوری اطلاعات . بخش هفتم »
