مهارتهای موردنیاز یک مدیر پروژه موفق

[ADMIN]

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

[ADMIN]

مشتری رو هر چه سریعتر درگیر پروژه کنید

الگوهای قدیمی توسعه نرم افزار مشتمل بر دریافت نیازهای پروژه از مشتری و رفتن به سراغ کدنویسی و تست کردن آن در زیر یک پوشش مخفیانه بود. در نهایت، مشتری نمیفهمه که ما چکار میکنیم، درسته؟ در پایان پروژه، شنل جادویی ما کنار میرفت و مشتری با «اوه» و «آه» به استقبال نبوغ ما توی تولید محصول میومد. هرچند، بیشترین عکس العمل مشتریها این بود: «خوب، میدونم که شما زحمت خیلی زیادی برای این کار کشیدین، ولی اون چیزی که من میخواستم این بود که...»

امروزه، راز موفقیت پروژه توی درگیر کردن مشتری توی کار، به محض اینکه یه چیزی برای نمایش دادن بصورت بصری برای اونها وجود داشته باشه، نهفته است. چقدر خوبه که بجای آخر کار که پروژه رو به خیال خودمون کامل کردیم، همون موقعی بفهمیم یه مشکلی توی کار وجود داره که شروع به حرکت توی مسیر اشتباه کردیم!

هرچقدر توی زمانبندی انجام پروژه، به سمت جلو حرکت میکنیم، هزینه های تغییرات بطور تصاعدی بالا میره. زمان کدنویسی مجدد، تست دوباره و به کار گیری دوباره نرم افزار جدید، و بررسی میزان سازگاری و ادغام بخشهایی از کد که تغییر کرده با بقیه کدهای پروژه، میتونه پروژه رو به میزان زیادی به تأخیر بندازه. و درصورتی که تغییرات موردنیاز، اونقدر بزرگ باشه که بخواد کل سیستم رو تحت الشعاع قرار بده، هر دو مورد «زمان» و «هزینه» افزایش پیدا میکنه و در اکثر موارد، مشتری زیر بار هیچکدوم از اینها نمیره و میگه: «من که همون اول توضیح دادم چی میخوام. الان تازه باید دعا کنین برای تأخیرتون جریمه نگیرم».

تصمیمات صحیح برنامه نویسی توی مشکلات خیلی جزئی، حس خوبی به توسعه دهنده نرم افزار و مدیر پروژه میده و باعث جلوگیری از هرج و مرج و آشوب توی محیط کاری در طی زمان استفاده از نرم افزار میشه.

من یه شرکت آموزشی رو میشناسم که 5 میلیون دلار هزینه برای بازنویسی نرم افزار سفارش دهی (فروش) خودش کرد. قبلاً شماره ردیف اقلام سفارش داده شده، با محصولی که سفارش داده شده بود، به شکل منطقی تطابق داشت. برای مثال، 4125 میتونست یک راهنمای دانش آموز باشه، 4225 یک دیسک تمرین کارآموز، 4325 یک راهنمای مربی، 4425 سرفصلهای دوره برای بازاریابها و... بود. شما میتونستین تمام این اقلام رو با فرمت 4X25 سفارش بدین.

هر روز، عمده فروشها در 140 مکان در دنیا، سفارشهای تکراری از اقلام مختلف رو بارها و بارها ثبت میکردن و خیلی زود، کدهای محصولات رو حفظ کردن. وقتی که شما کد یک راهنمای دانش آموز رو میدونستین، میشد به راحتی بقیه کدها رو حدس بزنید و درنتیجه سفارش دادن خیلی سریع انجام میشد.

توی طراحی مجدد، تیم پروژه به هر شکلی فراموش کرد که روشی که مردم واقعی مدتها برای سفارش دادن بهش عادت کرده بودن رو درنظر بگیره. توی طراحی جدید، ارتباط منطقی بین عناصر وجود نداشت. کالای 6358 ممکن بود همون راهنمای محصولی باشه که قبلاً 4125 بود. دیسک تمرین کارآموز الان 8872 شده بود و راهنمای مربی 3392 بود!

نه تنها کاربران باید هر دفعه برای محصولات «جستجو» و کدها و سیستم قبلی رو «فراموش» میکردن، بلکه الان هر محصول توی یک صفحه جدا توی سیستم قرار داشت.

بازاریابها خیلی عصبی شده بودن. سفارشها به اندازه یک حلزون کند شده بود. پروژه از مرزهای زمان و هزینه خودش خارج شده بود.

بعنوان یک مدیر پروژه، شما باید اجازه بدین مشتری با توسعه دهندگان نرم افزار، هرچه سریعتر و به دفعات زیاد صحبت کنه تا از این قبیل مشکلات پیش نیاد.

[ADMIN]

از بازی «موش رو بزن» پرهیز کنید

مدیران پروژه های نرم افزاری فشار زیادی درخصوص تحویل سریع کار تحمل میکنن. زمان خیلی حیاتیه. چطور میشه کارها رو سریع انجام داد؟

تصور کنید که دو برنامه نویس توی تیمتون دارین، «برنی» و «راب». هر دو خیلی توانمند هستند و اطلاعاتشون درمورد زمینه کاریشون یکسانه و مهارتهای برنامه نویسی یکسانی هم دارن. در طی توسعه، متوجه میشین که برنی کارهاش رو خیلی سریعتر از راب انجام میده.

درحالی که برنی تمرکزش روی تکمیل هرچه سریعتر کدهاست، راب زمان زیادی رو صرف نوشتن کدها و بازبینی و اصلاح اونها (Refactoring) میکنه. اصطلاح Refactoring به معنای کار مجدد روی کدهاست تا ساختار داخلی اونها رو ارتقاء بدیم، بدون اینکه توی کاربرد خارجی اونها تغییری ایجاد بشه. درواقع توی Refactor دوباره برمیگردیم سر کدی که کار میکنه و قبلاً فقط سریع نوشته بودیم تا کارمون راه بیفته ولی الان میخوایم منطق و ساختار داخلی اون رو ازنظر خوانایی کد و بهینه سازی و... ارتقاء بدیم تا بعداً اگه خواستیم قابلیتی بهش اضافه کنیم، کارمون راحتتر باشه.

راب متغیرها و متدها رو بهتر نامگذاری میکنه. وقتی مطمئن شد بخشی از کد کار میکنه، کد رو به بخشهای کوچکتر میشکنه و تستهایی مینویسه که مطمئن بشه هر تکه از کدش به درستی همون خروجی که میخواد رو تولید میکنه. وقتی کاملاً مطمئن شد، اعلام میکنه که کدنویسی اون قابلیت کامل شده.

اما فرض کنید شما این جزئیات رو نمیدونید. اگه فقط به سرعت کار نگاه کنید و اینکه کارهایی که مشتری خواسته انجام بشه، قطعاً برنی نیروی بهتری بوده، درسته؟

چند هفته میگذره و شما امکانات رو به مشتری نشون میدین. مطابق معمول، مشتری عاشق کارهایی هست که شما کامل کردین، ولی الان ازتون میخواد اوناه رو یکم تغییر و توسعه بدین. شما از برنامه نویساتون میخواین که این تغییرات رو کدنویسی کنن. وقتی که قابلیتهای جدید رو به مشتری نشون میدین، اونها قابلیتهایی که توسط راب درست شده رو تست میکنن و از تغییرات واقعاً راضی هستن.

متأسفانه متوجه میشن که یه چیزی توی قابلیتهایی که برنی اضافه کرده، عجیبه. با وجود اینکه برنی قابلیتهای جدید رو خوب کدنویسی کرده، اما یه چیزایی که قبلاً خوب کار میکردن دیگه کار نمیکنن. مشتری اینها رو بعنوان نقطه ضعف اعلام میکنه و شما از برنی میخواین که درستشون کنه. مشتری دوباره تست میکنه و الان حتی یه سری مشکلات عجیب و غریب جدیدتر بوجود میاد و یکسری بخشهای دیگه از کار افتادن. اینجا چه خبره؟

اگه یه بچه داشته باشین، میدونید که چه اتفاقی افتاده. برنی یک بازی «موش رو بزن» درست کرده. توی این بازی، بچه ها یه چکش چوبی یا پلاستیکی دارن و موشهایی که از توی یکی از سوراخهای تو بازی بطور تصادفی بیرون میپرن رو باید با چکش بزنن و باز یه موش دیگه از یه جای دیگه میپره بیرون. خوب این بازی برای اونها جذابه و همش از این غافلگیری که موش بعدش از کجا میپره بیرون هیجان زده میشن. البته اصلاح برنامه ای که مشکلات توی کدهاش هردفعه بطور تصادفی یه جایی بوجود میان و میپرن بیرون، قطعاً به جذابی اون بازی نیست. برعکس خیلی خسته کننده و غیرقابل پیش بینیه و توسعه نرم افزار رو کند میکنه. برنی اولش خوب و به سرعت داشت میدوید ولی توی یه مسیر اشتباه.

با وجود اینکه راب ابتدا کندتر بنظر میرسید، اما اون واقعاً داشت کد بهتری تولید میکرد. کیفیت بهتر کدهای اولیه اون بهش کمک کرد که تغییرات بعدی رو به شکل کاربردی و سریعتر تولید کنه. بعلاوه، تستهایی که در ابتدا نوشته بود، بهش کمک میکرد که فوراً بفهمه که کدهای جدیدش با بخشهای قبلی که نوشته بود، سازگاری دارن یا نه و کدهای قبلی که تغییر داده، همچنان درست کار میکنن یا خیر؟

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

از خودتون بپرسین سرعت براتون مهمه یا نجات دادن جونتون از یک روند فرسایشی توی فاز نگهداری پروژه؟

[ADMIN]

از صاحبان پروژه بخواین نیازهاشون رو بنویسن

شکست پروژه فقط یه مشکل برای شرکتهای امریکایی نیست. براساس یک نظرسنجی که چند سال قبل توسط یکی از مجلات پیشرو حوزه IT در ژاپن انجام شد، بیش از 75٪ پروژه هایی که توسط شرکتهای ژاپنی انجام شده بود، وقتی ازنظر استانداردهای کیفیت، هزینه و تحویل بررسی شدن، یک شکست محسوب میشدن.

توی ژاپن، مثل خیلی از کشورهای دیگه، علت اصلی شکست در هرکدوم از استانداردها اغلب یکسان بود: «نیازسنجی ضعیف». شرکتهایی که بیشتر در معرض ریسک بودن، همونهایی بودن که قابلیتهای تحلیل تجاری کمتری داشتن. وقتی به پروژه های مرتبط با فناوری میرسیدیم (مثل تولید نرم افزار)، موفقیت، با ارفاق «غیر محتمل» بود. این نتیجه نشون داد که چقدر سخته که نیازهای حقیقی یک پروژه نرم افزاری رو کشف کرده و تشخیص بدیم.

از اونجایی که این کار اینقدر سخته، خیلی از صاحبان پروژه ها (مثل مشتری ها، اسپانسرها یا مدیران اجرایی شرکتها) انتظار دارن که مدیر پروژه نرم افزاری، خودش نیازها رو تعریف و پالایش کنه. اونها هیچ راهنمایی بدردبخور یا تعریف دقیقی از چیزی که میخوان ارائه نمیدن. از اونجا که پروژه، نرم افزاریه و اونها ممکنه توسعه فرایند نرم افزار رو درک نکنن، اینطور فرض میکنن که نباید چیزهایی که انتظار دارن رو مشخص کنن.

مدیر پروژه نرم افزاری اغلب صلاحیت یا زمان کافی برای پیداکردن، انتخاب و اولویت بندی نیازهای پروژه رو نداره. بخصوص به این دلیل که ممکنه گروههای مختلفی توی پروژه درگیر باشن که ایده های اونها با هم درخصوص اینکه پروژه بعد از تکمیل باید چه کاری انجام بده، مغایرت داشته باشه.

وظیفه مدیر پروژه است که وقت بگذاره و با اونهایی که روی پروژه نرم افزاری سرمایه گذاری کردن صحبت کنه تا بهشون کمک کنه دقیقاً نیازهاشون رو قبل از شروع پروژه تعریف کنن. انجام دادن سریع این کار مهمتره یا اینکه باگ کمتری داشته باشه، یا با کمترین بودجه ممکن انجام بشه؟ شما نمیتونید همه رو با هم داشته باشین. چه منابع و مهارتهایی برای ساخت نرم افزاری که اونا میخوان ضروریه؟ آیا اونها این منابع رو در اختیار تیم میگذارن یا نه؟

نرم افزار قراره چطوری مورد استفاده قرار بگیره تا ساختار موردنظر اونها رو اجرا کنه یا برای شرکت پولساز بشه؟ آیا محدودیتهای زمانی واقع گرایانه هستن؟ آیا توی قرارداد مشتری نوشته شدن؟ پروژه باید به تاریخ رسمی خاصی برسه یا بخشی از یک طرح بازاریابیه که بطور استادانه ای درست شده؟

بدون درنظر گرفتن دقیق و جدی چیزهایی که باید توی این پروژه پیاده سازی بشه، توی فاز نیازسنجی، موفقیت پروژه به شدت با خطر مواجه میشه. به خاطر داشته باشین که صاحبان پروژه نیاز به منتقل کردن کاری که میخوان نرم افزار براشون انجام بده دارن، نه اینکه برنامه نویسها چطوری قراره اون نتیجه رو تولید کنن.

صاحبان پروژه رو متقاعد کنید که اونها باید از ابتدا تا انتها درگیر فرایند تولید نرم افزار باشن. طراحی منسجم نیازها یک اتصال شفاف بین مورد تجاری، اهداف پروژه و خروجی نهایی اون ایجاد میکنه. درغیر اینصورت پروژه نمیتونه به شکل رضایت بخشی اون چیزی که مدنظرشونه رو تولید کنه.

یک نرم افزار شکست خورده، بیشتر از همه به صاحبان پروژه آسیب میزنه چون اونها پول صرف پروژه کردن و انتظار داشتن از نرم افزار برای برگشت سرمایه گذاریشون استفاده کنن.