پاداره کردن افراد و پروژه‌ها کار ساده‌اي نيست، هر چند که اين روزها، به ظاهر کاري آسان، براي مديران و افراد مختلف محسوب مي‌شود. من طي پانزده سال گذشته با پروژه‌هاي بسياري در سراسر جهان سر و کار داشته‌ام و در اين جا قصد دارم برخي از عوامل موفقيت خود در اين پروژه‌ها را براي شما بازگو کنم.
يکي از بزرگ‌ترين مشکلاتي که در پروژه‌هاي جهاني با آن رو به رو مي‌شويم، اين است که چه کسي مسئوليت کدام‌ يک از بخش‌هاي پروژه را بر عهده دارد. برخي اوقات، بخش‌هايي از يک سيستم به يک‌ديگر وابسته هستند، بدون آن که مدير پروژه از چگونگي آن اطلاع داشته باشد. اگر شما و تيم پروژه‌تان بتوانيد اسناد و مدارک مبتني بر مولفه‌هاي سيستم در دست توليد را به خوبي تعريف و تعيين کنيد، آن وقت اين شانس را داريد که با اطمينان بر اساس برنامه‌ي توليد خود پيش ‌رويد.
بيشتر وقت‌ها، هنگامي که به بررسي پروژه‌ها مي‌پردازم، با مراحلي نظير «نيازها تکميل شد» و يا «کد تکميل شد» مواجه مي‌شوم. به ياد ندارم که تاکنون پروژه‌هايي را ديده باشم که به راستي داراي مرحله‌ي مهم «تکميل نيازها» باشد و نيازهاي مورد نظر در آن‌ها به مرحله‌ي تکميل رسيده باشد، اما شاهد پروژه‌هاي موفقي بوده‌ام که در آن‌ها نيازها مي‌توانسته‌اند از بيش‌ترين اهميت برخوردار باشند و يا به عنوان يک خط اصلي محسوب شوند. همچنين شاهد پروژه‌هايي بوده‌ام که درآن‌ها مهم‌ترين نيازها به خوبي تعيين شده و بدين ترتيب ادامه‌ي کار بر روي پروژه را ميسر ساخته‌اند. از آن جايي که قصد دارم با روش‌هاي سريع‌تري پروژه‌ها را پيش ببرم، بنابراين کم‌تر به تعيين مراحلي نظير «تکميل نيازها» توجه مي‌کنم. در عوض از روش‌هايي نظير تعيين نيازهاي اوليه در پروژه‌هاي خود بهره مي‌گيرم.
بعضي وقت‌ها، از مراحل مبتني بر نيازها صرف نظر مي‌کنم، به ويژه اگر تيم‌هاي پروژه بر اساس خصوصيات و کارکرد بخش‌هاي متفاوت پروژه تشکيل شده باشند. در چنين مواردي، مراحل مهمي نظير "تکميل کارکرد يک" را تعريف مي‌کنم. در اين زمان، هر کارکرد که به مرحله‌ي تکميل برسد، مي‌توان تست سيستم را آغاز کرد. به عنوان يک مدير پروژه، ياد گرفته‌ام که مزيت پياده‌سازي بر مبناي کارکرد آن است که چنانچه افراد طي انجام مراحل مختلف پروژه با مشکلي مواجه شوند، من خيلي سريع از آن باخبر شوم. به طور مثال، اگر زمان پياده سازي «کارکرد يک» بيش از آن چه که مورد انتظار ما بوده، به طول انجامد، بايد به بررسي بقيه برنامه بپردازم تا بدانم وجود چه مشکلاتي را بايد به تيم پروژه يادآور شوم. زماني که هر يک از کارکرد‌ها تکميل شوند، مي‌توان تست سيستم را آغاز کرد. شما هنوز هم مي‌توانيد از مراحلي نظير "تکميل کد" و يا " تکميل کارکرد‌ها" استفاده کنيد، البته در صورتي که به مفهوم و تعريف «تکميل» پي برده باشيد. از آن جايي که معني تکميل به صورت کلي و عمومي، فهرست‌بندي تمامي کارکرد‌ها است، من ترجيح مي‌دهم مراحل بيشتري را ايجاد کنم که پايان يافتن هر يک از مشخصه‌هاي تحت پردازش را نمايان سازد.
مهم نيست که اين کار را چگونه انجام دهيد، فقط بايد مطمئن باشيد که در برنامه‌ي پروژه‌ي خود داراي مراحلي هستيد که چگونگي و زمان فرايند هر يک از گروه‌ها را بر روي سيستم منعکس مي‌کند. به اين ترتيب، چنانچه معماري و يا کارکرد‌هاي پروژه را بر اساس بخشي که در آن واقع شده‌اند، سازمان‌دهي کنيد، شما و تيم پروژه همچنان در جريان وضعيت جاري پروژه قرار خواهيد گرفت.
به طور کلي، من به راه‌حل‌هايي که بدون درک مفهوم "تکميل" به پايان دادن فرايندها مي‌پردازند، علاقه‌اي ندارم. من متوجه شده‌ام که حتا زماني که از توليدکنندگان درخواست مي‌کنم که «تست واحد» را بر روي کد خود انجام دهند، برخي از آن‌ها تصور مي‌کنند که تست واحد به معناي کامپايل کردن کد است. افزون بر اين، دريافته‌ام زماني که از تست‌کنندگان مي‌خواهم تا بر روي بخشي از نرم‌افزار متمرکز شوند، تصور مي‌کنند که تنها مي‌توان به تست مراحل واضح و بديهي اکتفا کرد.
از آن جايي که انتظار دارم گونه‌هاي متعددي از تست بر روي پروژه‌ها صورت گيرد، نمي‌توانم تنها از "تکميل تست" به عنوان مرحله‌اي مهم نام ببرم. به عنوان مثال، زماني که مي‌گويم «کارکرد يک» تکميل شد، فهرستي به شرح زير ارايه مي‌دهم:
کد «کارکرد يک» بدون اخطار بر روي تمامي پلاتفرم‌ها کامپايل مي‌شود.
تست‌هاي واحد «کارکرد يک» مورد بررسي قرار گرفته و اجرا مي‌شوند.
Smoke Test تستي که به سرعت و براي مرور دوباره‌ي سيستم و آگاهي از نقاط ضعف آن صورت مي‌گيرد) «کارکرد يک» انجام شد.
«کارکرد يک» مورد آزمون قرار گرفته و تعريف شد. تست با موفقيت صورت گرفت.
از فهرست بالا مشاهده مي‌شود که من و تيم پروژه، نمي‌گوييم «کارکرد يک» تکميل شد، مگر آن که تمامي کدها مورد آزمايش قرار گرفته و به درستي و بدون هيچ کم و کاستي اجرا شوند.
اگر شما مدير يک تيم پروژه‌ي کوچک هستيد، مي‌توانيد با توليدکنندگان گفت و گو کنيد و موافقت آن‌ها را براي تهيه‌ي چنين فهرست‌هايي در مراحل متعدد انجام پروژه کسب کنيد. اما هرچه تيم شما بزرگ‌تر باشد و هرچه تيم‌هاي پروژه از نظر موقعيت جغرافيايي در نقاط مختلفي از جهان گسترده‌تر باشد، شما و تيم‌تان براي اطلاع از موقعيت و وضعيت واقعي پروژه به توافق‌هاي بيشتري با توليدکنندگان نياز خواهيد داشت.
بيش‌ترين و مهم‌ترين عملکردي که يک مدير و يا مدير پروژه مي‌تواند درباره توليد پروژه‌ها انجام دهد، برقراري اطمينان و اعتماد در ميان تمامي تيم‌ها است. دو سال پيش، به بررسي پروژه‌اي مي‌پرداختم که داراي تيم‌هاي متعدد و پراکنده‌اي در چندين کشور اروپايي و آسيايي بود که تعداد کل آن‌ها، به هفت تيم مي‌رسيد. مدير ارشد اين پروژه نگران هزينه‌هاي توليد بود، بنابراين تصميم گرفت جوي رقابتي در ميان تيم‌ها به وجود آورد. تيم‌هايي که مراحل مهم را زودتر به پايان مي‌رساندند، پاداش اندکي دريافت کرده و بر سر کار خود باقي مي‌ماندند. در مقابل، افرادي که در برنامه‌ريزي خود با شکست مواجه مي‌شدند، از ادامه‌ي کار محروم مي‌شدند.
در پروژه‌هاي بزرگ که داراي تيم‌هاي متعددي است، هر تيم پروژه به صورت منفرد با هر يک از مراحل مهم پروژه مواجه شده است. اگرچه پروژه در نهايت بدون نتيجه باقي مانده و قابل استفاده نبوده، اما هر فرد با مراحل مهمي که خود مسئول انجام آن بوده، برخورد کرده است. بر اين اساس، بي‌اعتمادي ميان تيم‌هاي متعدد، مانع موفقيت پروژه خواهد شد. حتا بدون وجود مديريت ارشد، لازم است اين تيم‌ها از اين موضوع آگاه باشند که در انجام يک پروژه‌ي مشترک، تمامي تيم‌ها با هم برابر و شريک هستند و بايد براي يک سازمان‌دهي مناسب با يکديگر همکاري کنند
منابع:
http://ictworld.blogsky.com/
www.computerworld.com
http://vista.ir
ارسال توسط كاربر محترم : mohammad_43