تمدن بشری همیشه از هر دو روش متعین و تطبیقی استفاده کرده است و نشانه‌های آن را می‌توان در بسیاری پروژه‌های باستانی دید. نخستین نسل کامپیوترها محدودیت‌های فراوان و مخاطب ویژه و اندکی داشتند که باعث می‌شد ساخت نرم‌افزارهایشان نیاز به روشی متعین داشته باشد. با پیشرفت سخت‌افزار، کاهش محدودیت‌ها، و دگرگونی نوع و گستردگی مخاطب نرم‌افزارها، روش‌های متعین دیگر گزینه خوبی برای ساخت نرم‌افزار نبودند، ولی دست‌اندرکاران این نوع پروژه‌ها همچنان به عادت گذشته می‌کوشیدند روش‌های متعین را به‌کار گیرند.
تحمیل روش‌های متعین بر پروژه‌های نرم‌افزاری همچنان ادامه پیدا کرد، تا زمانی که برنامه‌نویسان و مدیران تیم‌ها بیشتر و بیشتر از وضعیت ناراضی شدند و گرایش به ساخت محصول به شیوه تطبیقی پیدا کردند. سرانجام، گروهی از این افراد دورهم گرد آمدند تا به رویکرد خود رسمیت بخشند و برای آن نام چابک را انتخاب کردند.
متاسفانه اختلاف‌ها و مشکل‌های فراوانی که در این روند به وجود آمده بود ذهنیتی منفی درباره روش‌های متعین برای این افراد و کسانی که ادامه‌دهنده راهشان شدند به وجود آورد. به عبارت دیگر، به‌جای اصلاحی تدریجی، انقلابی خونین به وجود آمد. کمی پس از انقلاب هم گروهی کوچک مهره‌های اصلی را کنار زده، قدرت مطلق را به دست گرفتند. دایما هم درباره دشمن بیرونی هشدار می‌دهند! برای اطلاعات بیشتر می‌توانید به کتاب «قلعه …
متاسفانه واقعیت این است که اختصاصی‌سازی کار ساده‌ای نیست. برخی گمان می‌کنند که اختصاصی‌سازی به معنی انتخاب هیجان‌انگیزترین عناصر از سیستم‌های مختلف و کنار هم قرار دادن آن‌هاست، با این‌که چنین کاری سازگاری درونی سیستم و بنابراین کارآیی آن را از بین می‌برد. اختصاصی‌سازی نوعی ساخت سیستم است و همچون هر ساخت سیستم دیگری باید با دیدی همه‌جانبه و موشکافانه انجام شود.
در بیشتر سیستم‌ها مسئولیت اختصاصی‌سازی با مدیر پروژه است، ولی کسی که از هر جهت دیگر مدیر پروژه بسیار خوبی باشد شاید توانایی ساخت سیستم نداشته باشد. این‌که از مدیر پروژه‌ها انتظار داشته باشیم که بتوانند سیستم‌ها را اختصاصی‌سازی کنند همیشه واقع‌بینانه و منصفانه نیست. این مسئله در DSDM که یکی از متدولوژی‌های چابک نسل نخست است به رسمیت شناخته شده است، و از این رو، در انتخابی هوشمندانه، نقشی با نام مربی DSDM به متدولوژی افزوده‌اند که مسئولیت اختصاصی‌سازی و برخی مسایل دیگر را بر دوش دارد.
پیش از اجرای هر پروژه‌ای باید چرایی انجام آن را به‌خوبی درک کرد زیرا هرآن‌چه در پروژه انجام می‌شود باید با آن همسو باشد و تصمیم‌های کلان بر آن پایه گرفته شوند. این درک محدود به مدیر پروژه نیست و همه اعضای تیم به آن نیاز دارند.
چندی پس از آغاز پروژه ناسا برای فرستادن اولین فضانورد به ماه، رییس جمهور وقت آمریکا، کندی، از ناسا بازدید کرد. در هنگام بازدید، یکی از مستخدم‌های ناسا را جارو به دست دید و مانند هر رییس جمهور دیگری که همیشه کوشش می‌کند خود را مردمی جلوه دهد، با او سلام و احوال‌پرسی کرد. از مستخدم پرسید که کارش چیست و او در پاسخ گفت «کمک می‌کنم که فضانورد به ماه بفرستیم!»
اگر بتوانید بستری در پروژه به وجود آورید که همه برخوردی همانند آن مستخدم داشته باشند، احتمال موفقیتتان به‌مراتب بالاتر خواهد بود.
هنگامی که همه جنبه‌های فنی بر دوش متخصصان فنی پروژه گذاشته شود، چه کاری برای مدیر پروژه باقی می‌ماند؟ هماهنگی، حل اختلاف، مذاکره و تسهیل‌گری برخی از موارد نسبتا بدیهی هستند، ولی مسئولیت مدیر پروژه به این موارد محدود نمی‌شود.
یکی دیگر از مسئولیت‌های مدیر پروژه این است که فضای مناسبی برای رشد حرفه‌ای اعضای تیم فراهم کند. بله، مدیر پروژه در این باره مسئول است. این یکی از جنبه‌های اخلاق و رفتار حرفه‌ایست. برای اطلاعات بیشتر می‌توانید به این منابع مراجعه کنید:
خلاصه این‌که از اعضای تیم پروژه و منابعی که در اختیار پروژه گذاشته شده است مراقبت کنید. امانت‌دار و قابل‌اعتماد باشید و الزامات و قوانین را تا جایی که خلاف اخلاق نباشند پاس دارید.
نکته پایانی این است که برای انجام همه این موارد باید شنونده خوبی باشید. برای پاسخ دادن گوش نکنید، بلکه برای فهمیدن گوش کنید. منتظر نمانید که برای گفتگو به شما رجوع کنند، بلکه برایش پیش‌قدم شوید تا هر دشواری یا کمبودی را در زودترین زمان و پیش از آن‌که پیچیده‌تر شود حل کنید.
کیفیت محصول و شیوه ساخت آن را به‌کوتاهی بررسی کردیم. عنصر دیگری که باید در مدیریت کیفیت مد نظر باشد، کیفیت سیستم مدیریت پروژه است. بله، این مسئله حتی دربرگیرنده کیفیت سیستم مدیریت کیفیت هم می‌شود!
نمونه خوبی از مدیریت کیفیت مدیریت پروژه در P3.express همتاداوری (peer review) دوره‌ایست. در آغاز هر ماه، پس از این‌که برنامه‌های کلان بازبینی و برنامه تفصیلی ماه پیش رو آماده شود، مدیر پروژه باید از یکی دیگر از مدیر پروژه‌هایی که در سازمان وجود دارد درخواست همتاداوری کند. مدیر پروژه دوم زمانی را صرف می‌کند و همراه هم کارهای انجام شده را بررسی می‌کنند تا اگر مشکلی وجود داشت کشف شود. پیشنهاد P3.express این است که در صورت امکان هر ماه از فرد تازه‌ای برای همتاداوری دعوت کنید.
یکی از امتیازهای همتاداوری کشف زودهنگام مشکل‌های احتمالیست، ولی افزون بر آن، در طی این فرآیند هر دو فرد از یکدیگر نکته‌های جالبی می‌آموزند. این فرصت طلایی را به هیچ وجه نباید از دست بدهید. پیشنهاد می‌کنم که به هر متدولوژی‌ای که دارید همتاداوری هم بیفزایید.
یکی از دو موضوع مدیریت کیفیت، محصول و شیوه ساخت آن است که موضوعی فنیست وابسته به نوع محصول؛ برای نمونه:
پروژه‌های نرم‌افزاری آزمایش‌های خودکار و دستی فراوانی دارند که مطمئن شوند نرم‌افزاری که در اختیار کاربر قرار می‌گیرد کارکرد درستی خواهد داشت. در کنار آن می‌توان از روشی مانند pair programming نیز برای بهبود کیفیت بهره برد. در این روش هرروز اعضای تیم به گروه‌های دونفره تقسیم می‌شوند. هر گروه روی قابلیتی کار می‌کند؛ یکی از آن دو نفر برنامه‌نویسی می‌کند و نفر دیگر نظاره‌گر است و در هنگام کار پیشنهادهایی می‌دهد. هر نیم ساعت تا یک ساعت این دو نفر جایشان را با یکدیگر عوض می‌کنند.
در پروژه‌های ساختی که بتنی باشند روش‌های آزمایش مخرب و نامخرب گوناگونی برای بتن وجود دارد، ولی افزون بر آن آیین‌نامه‌ها و استانداردهایی هم درباره نوع شن و آب، نگهداری سیمان، شیوه مخلوط کردن مواد، شیوه نگهداری از بتن پس از بتن‌ریزی و همانند آن وجود دارد که رعایتشان احتمال رخداد مشکل را کمتر می‌کند.
به عنوان مدیر پروژه‌ای که الزاما فنی هم نیست چگونه می‌توانید از این جنبه‌های فنی اطلاع داشته باشید؟
مانند همیشه، نیازی نیست که شخصا همه این موارد را بشناسید، بلکه باید از تیم متخصصی که در کنار خود دارید کمک بگیرید. آنچه برای شما لازم است این است که مطمئن باشید روند مدیریت کیفیت فنی به‌خوبی شناسایی، مستند، و اجرا …
همانگونه که گفته شد، بهتر است روندی برای تیم پروژه وجود داشته باشد که به‌جای کار روی انبوهی از تحویل‌شدنی‌ها، روی شمار اندکی کار کرده، آن‌ها را به سرانجام برساند. بهتر است مدیر پروژه کارهای پایان یافته را بررسی و تایید نیز بکند.
تایید تحویل‌شدنی‌ها بر پایه گستره و کیفیت آن‌هاست. باید پیش از آغاز به کار روی تحویل‌شدنی‌ها از نیروهای فنی پروژه کمک بگیرید و گستره و کیفیت تحویل‌شدنی‌ها را بر پایه الزامات و نیازهای ذی‌نفعان تعیین کنید. پس از این‌که کار به پایان رسد، بر پایه همان تعریف نخستینی که به کمک اعضای تیم شده بود کارشان را بررسی خواهید کرد. این بررسی به مفهوم نظارتی از بالا به پایین و با هدف خرده‌گیری نیست، بلکه کمکی دوستانه است از سوی فردی که شاید حتی فنی هم نباشد تا با نگاهی تازه، کمی دورتر از کار به آن بنگرد و تفاوت احتمالی آن را با آنچه افراد فنی در نظر داشته‌اند بسنجد و کمبودهای احتمالی را مشخص کند.
جلوگیری از بروز دشواری‌های بنیادین در زمان تحویل نهایی، افزایش بهره‌وری کار با محدود کردن کارهای موازی، و بسیاری دیگر از عناصر مفید پروژه مستلزم تعیین گستره و کیفیت تحویل‌شدنی‌ها پیش از ساخت است. پرینس۲ برای این کار سندی به نام شرح محصول دارد («محصول» در اینجا به معنی تحویل‌شدنی است) و P3.express این مشخصات را به شکل یادداشت در نقشه تحویل‌شدنی‌ها لحاظ می‌کند. متدولوژی خود را بررسی …