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