با آقاي دکتر ناظمي اولين بار در درس شبيه سازي را گذراندم. بعد ها تجربه دانشجو بودن ايشان را در درس هاي تحقيق در عمليات و سيستم هاي اطلاعات مديريت تکرار کردم و کماکان اين تجربه به شکل ديگري ادامه دارد.
ايشان را فردي مي شناسم که خوبي قادرند مفاهيم را به دانشجويان منتقل کنند. يکي از جذاب ترين کلاسهاي دانشگاه را دارند و معمولا مطالب را به شکل ساده ولي در عين حال ساختيافته منتقل مي کنند. هميشه شادند و اين انرژي مثبت را به دانشجويان خود نيز منتقل مي کنند.دانشجويان -مخصوصا دانشجويان فعال تر- با ايشان راحت هستند و به آقاي دکتر به راحتي و بدون رعايت تشريفات مي توان مراجعه کرد. از اين نظر هميشه ايشان و تدريسشان را دوست داشتم. اما آقاي دکتر ناظمي، روي ديگري هم دارد. امتحان ها! بسيار سخت گير بوده و معمولا نمره بالا به کسي نمي دهند.اما اينکار را آنقدر خوب انجام مي دهند که براي کسي جاي اعتراض نمي گذارند. نديدم کسي از اينکه در دروس ايشان نمره پايين گرفته باشد، پشت سرشان بدگويي کرده باشد. به نظرم حتي اگر حق واقعي کسي را ندهند، آنقدر استادانه اين کار را مي کنند که آدم نمي تواند راضي نباشد!!
حضور آقاي ناظمي را در ساليان نزديک در بين دانشجويان بيشتر احساس مي کنم، شايد به خاطر مسؤوليت ايشان است در تيم هاي ربوکاپ و شبيه سازي فوتبال دانشکده کامپيوتر دانشگاه شهيد بهشتي، که با تيم هاي مختلف موفقيت هاي فوق العاده خوبي در مسابقات جهاني داشته اند. اين روزها هم که شنيده ام در گير مسؤوليت جديدي هستند به عنوان معاون آموزشي دانشکده. خوب است اما اميدوارم ايشان را آنقدر درگير کار اجرايي نکند که نشود پيدايشان کرد.
اما بعد ....

چرا مي گويم ايشان مهندس استاد است، چون اگر مطلبي را تدريس مي کنند حتما پيشتر آن را به صورت عملي تجربه کرده اند، يادم مي آيد زمانيکه MIS داشتيم، از همکاران خود در خارج از دانشگاه مي خواستند که در کلاس ها شرکت کنند و به ما کمک کنند. مثالهاي خوبي از تجربيات موفق يا ناموفق خود در هر زمينه تدريس ضميمه درس مي کردند که تاثير محتوي آن را براي من يکي هم که شده بيشتر مي کرد.
و چرا مي گويم استاد مهندسي، چون کلاسهاي مهندسي نرم افزار ايشان به نظرم عالي است. هر چند خودم در زمان دانشجويي با ايشان درس مهندسي نرم افزار نداشتم، اما در زمان تدريس نرم 1 در شهيد بهشتي ايشان منهدسي نرم افزار 2 تدريس مي کردند به کمک دوست عزيز و موفقم، حسن گردش. کنفرانس هاي مداوم، طرح مسائل جديد و فنآوري هاي روز و ارائه مطالب متنوع و مهم در اين زمينه، سطح آگاهي دانشجويان را در اين زمينه بسيار بالا مي برد.
در کل به نظرم آقاي دکتر ناطمي توانسته اند تعادل خوبي بين فعاليتهاي دانشگاهي و کاري خود ايجاد کرده اند که نه تنها روي هم تاثير منفي ندارد، بلکه تاثير مثبت آن بسيار زياد است. هم در کار که از الگو هاي جديد مهندسي نرم افزار استفاده مي کنند و هم در تدريس که از تجربيات عمليشان به شکل جالبي استفاده مي کنند.
آقاي دکتر تاليفات متعددي هم در زمينه شبيه سازي و تئوري بازيها دارند. هر چند من از آنها چيزي سر در نياوردم! بماند!
در کل پيشنهاد مي کنم اگر در شهيد بهشتي هستيد و يا در جايي که ايشان هم تدريس مي کنند (نمي دانم؟) حتما با ابشان درس بگيريد، فقط بايد قيد نمره را بزنيد مگر آنکه مثل تراکتور روي مطالب کلاس کار کنيد. هيچ وقت بلايي را که سر يکي از دوستان هم دوره اي من آوردند از ذهن ما فراموش نمي کند. (خلاصه اينکه اول به وي نمره -1- دادند! هم من هم اون بيچاره نزديک بود سکته کند، بعدا فهميديم که شوخي کرده اند و آن دوست من [...] درس را پاس کرد، آنروزها چقدر نفرينشان کرديم!).
نکته منفي ايشان -به نظر من- سيگار کشيدن است. وحشتناک سيگار مي کشند . که شايد اين هم طبيعي باشد، نرم افزاري ها يا سيگار زياد مي کشند و يا چاي زياد مي خورند و يا هردو! اميدوارم که حداقل يکي را ترک کنند.
از شاگردي ايشان هم ديروز ها و هم امروز ها لذت برده و مي برم و به آن افتخار مي کنم.
همين!

نرم افزار هم مانند هر کالاي ديگري بايد ساخته شود. فرآيند توليد آن هم مانند همه فرآيند هاي توليد صنعتي، از "تفکر کارگاهي" تا "تفکر کارخانه اي" را طي کرده است.
به فرآيند صنعتي که دقت کنيد، مي بينيد که بعد از آنکه بشر به اين صرافت افتاد که خودش نمي تواند همه کار بکند و مثلا يک کلبه را به صورت کامل بسازد،  ابتدا به صورت فردي و در مغازه ها و کارگاه هاي تخصصي کار شروع شد، آهنگري ها، نجاري ها یا در و پنجره سازي و .... و بعد ديد که نمي تواند با این روش برج بسازد، نمي تواند خودرو را در حجم انبوه توليد کند ، طرز فکرش را عوض کرد و کارخانه ها را ساخت تا بتوانند در يک خط توليد به صورت انبوه، کالاي استاندارد توليد کنند و مشتري ها هم عادت کردند که خود را با کالا تطبيق دهند.
همين اتفاق در نرم افزار افتاد، از جايي که به صورت اختصاصي براي هر مشتري پروژه توليد داشتيم، تا بسته هاي نرم افزاري (Package)  که به صورت انبوه توليد مي شد و فروش مي رفت و تا ERP که مي گوييم استاندارد است و هر مشتري خودش را تطبيق مي دهد و يا سيستم به صورت کم، تغيير داده مي شود تا نياز مشتري را فراهم کند.اين توليد هم مانند توليد هاي ديگر نياز به تحليل، طراحي و پياده سازي دارد. مديريت پروژه مي خواهد توليدش و همان مسائل رادارد.

فرآیند مدیریت پروژه (سازماندهی، برنامه ریزی و نظارت) به عنوان یک اصل جدانشدنی از هر پروژه ای در همه صنایع (منجمله نرم افزار) هم وجود دارد.
اما نرم افزار به لحاظ عوامل ماهیتیش چنان با بقیه کالاهای صنعتی متفاوت است که می بینیم در روشهای توسعه آن تنوع زیادی وجود دارد و هر روز یک مدل جدید برای توسعه نرم افزار می بینیم. این تفاوت ها را به طور خلاصه می توانیم شامل موارد زیر بدانیم:
1- نرم افزار پیچیده است (Complexity): به تعبیری "کاهش پیچیدگی قلب توسعه نرم افزار است." یک برنامه کوچک گاهی هزاران خط فرمان می شود و توسعه آن به هر نحو مشکل است. روشهایی مانند ماژول بندی و .... آمده است، اما هنوز هم پیچیدگی یکی از مهمترین اجزاء جدانشدنی نرم افزار ها و فرآیند تولید آن است.
2- نرم افزار انتزاعی است (abstraction) : شما نمی توانید به شکل فیزیکی آن را لمس کنید و نشان دهید. نه خودتان واقعا می توانید همه آن را یکجا در دست بگیرید و مشکلتر آنکه مشتری ها عقلشان به چشمشان است! و شما عاجز از نمایش کار خود. نرم افزار انتزاعی ترین جزء تولید است.
3- نیازها کامل نیست. (Uncomplete Requirements) : اغلب موراد، پیش از ساخت واقعی نرم افزار، همه نیازهای مشتری یا استخراج نشده و یا هنوز معلوم نیست. در پایان پروژه، تازه مشتری می فهمد که واقعا چه می خواهد.
4- فنآوری به سرعت تغییر می کند (Technology Changes Rapidly): سرعت تغییرات در فنآوری های ساخت نرم افزار فوق العاده سریع است. هر روز بستر و سیستم عامل جدید، هر روز تغییر سخت افزار، تغییر زبانهای برنامه سازی و .... کدام فنآوری را می شناسید که به این سرعت تغییر کند.
5-تجربه های موفق بالغ نشده اند. (Immature Best Practices): به خاطر رشد سریع، اغلب تولید کنندگان به خوبی مهارت های تولید را کسب نکرده اند. معمولا در پروژه ها عوامل کیفی کمتر دیده می شود و بنابراین تجربه های موفق کمتر بدست می آیند.حتی در صورت وجود، به دلیل تغییرات سریع فنآوری، کمتر در پروژه های بعدی می توانند الگو باشند.
6- فناوری اطلاعات بسیار گسترده است. (Technology is a Vast Domain): در این که شک ندارید! کسی نیست در این زمینه که همه فن حریف باشد (علامه دهر در نرم افزار نداریم!) بنابراین کسی نمی تواند به تنهایی به همه قسمت های یک پروژه اشراف داشته باشد.
7-تجارب فنآوری ناقص هستند. (Incomplete Technology Experience) : فنآوری های جدید و نسخ های جدید ابزارها اغلب آنقدر با نسخه قبلیشان تفاوت دارد که به سرعت تجربه افراد در این زمینه خارج از رده می شود. تجارب اکثر در موقع کار بدست آمده و بعد از آن کمتر به درد می خورند.
8- توسعه نرم افزار اکتشافی است. (Software Development is Research) : به دلیل عدم شناسایی نیازها و عدم دانش مشتریان نرم افزار با آن، فرآیند تولید اغلب ماهیت تحقیقاتی و یا اکتشافی به خود می گیرد. ابزارها نیز جدیدند و توسعه دهنده باید آموزش استفاده از آنها را کسب کند. بنابراین فرآیند توسعه نرم افزار فقط ساخت آن نیست، یادگرفتن آن است که با چه راهی می توان به نتیجه رسید.
9- کارهای تکراری خودکار هستند. (Automated Repetetive works) : در نرم افزار و تولید آن، به حدی از خودکار سازی برای فرآیند های تکراری رسیده ایم که در تولید های دیگر هنوز بحث آن هم مطرح نشده است، حجم بالای استفاده مجدد (reuseability) از قطعات آماده، برون سپاری تولید (Outsourcing) و.... نمونه هایی از این خودکار سازی است.
10-ساختن در واقع طراحی است . (Construction is Actually Design) : همه فرآیند های صنعتی مراحل مشخصی دارند (تحلیل، طراحی و اجرا : یک مدل خطی خوش تعریف) اما نرم افزار چنین نیست، در مرحله پیاده سازی و اجرا، نیازها به مرور تشخیص داده می شوند و این باعث می شود طراحی تا پایان ادامه پیدا کند. حتی در زمان نگهداری و پشتیبانی نیز، فرآیند طراحی به شکل جدی مطرح است.
11- تغییرات راحت پنداشته می شوند. (Changes Considered easy) : تغییر نیاز در فرآیند های تولید دیگر توسط مشتری بسیار سخت دیده می شود و وی سختی تغییر طراحی را در پایان پیاده سازی می فهمد و بنابراین آن را مطرح نمی کند و یا اگر مطرح کرد هزینه آن را می پذیرد. اما در نرم افزار به خاطر ماهیت انتزاعی بودنش این تغییرات ساده فرض می شوند. چون نرم افزار به سادگی قابل توسعه است، مشتری متوجه نیست که چیزی که می خواهد واقعا چه هزینه ای برتولید کننده تحمیل می کند تا آن را اجرا کند. اغلب تغییرات ساختاری نیز بسیار ساده فرض می شوند و تولید کننده را وادار به ساخت آن.
12- تغییرات اجتناب ناپذیرند. (Inevitable Changes) : ایا در نرم افزار موقعیتی هست که تغییر نکند. همه چیز از فنآوری تا نیاز مشتری تا تیم تولید تغییر می کند و این تغییرات بسیار سریع و غیر قابل اجتناب می باشند. گریزی نیست که آنها را در نظر بگیریم.به قولی تنها چیز "ثابت" در نرم افزار خود مفهوم "تغییر" است. هیچ نرم افزاری در ابتدا کامل نیست و این تغییرات است که باعث می شود مطابق نیاز در بیاید.

این دوازده مورد و موارد دیگری از این دست، تفاوت های ماهوی و سختی و پرخطر بودن تولید نرم افزار را نسبت به سایر تولید های صنعتی نشان می دهد. نتایج یک تحقیق که در سال 2000 انجام شده است نشان می دهد که تنها 28 درصد پروژه های نرم افزاری موفق بوده اند، 23درصد متوقف شده اند و الباقی (یعنی 49%) با مشکلات جدی نظیر تاخیر تحویل، افزایش بودجه و یا عدم برآورده کردن نیازها مواجه بوده اند.
این مشکل است، اما راه حل کجاست؟ طبیعی است در "مدیریت پروژه"! در آینده به بحث مدیریت پروژه به صورت جدی تری خواهم پرداخت.
همین!

در نوشتن این مطالب، کمک زیادی گرفته ام از کتاب "Software Project Secrets: Why Software Projects Fail" . گرچند هنوز کامل نخواندمش، خواندنش را به همه توصیه می کنم. مخصوصا کسانی که تجربه کار در پروژه های مختلف را دارند و مسائل آن برایشان ملموس است.

George Stepanek, "Software Project Secrets: Why Software Projects Fail" , Apress, 2005

"رادمان نیاز به یک همکار تمام وقت به عنوان مدیر فروش دارد."
 شرایط : مدرک مرتبط، عقل سلیم، پیگیر، آشنایی با نرم افزار و فرآیند مهندسی فروش ، متعهد و مسؤول، علاقه مند  و توانمند به شرکت در جلسات فنی و فروش، آماده انجام کار فشرده، سخت و پویا در زمینه فروش نرم افزار.
علاقه مندان از طریق پست الکترونیک و یا تلفن های تماس رادمان ، رزومه خود را ارسال نمایند.

شرکت ها ، محل گذرند! آدم ها می آیند و می روند. ما هم از این قاعده مستثنی نیستیم. در رادمان نیاز به همکاری افراد مختلفی داریم که به روش های مختلف جذب می کنیم. اغلب هم نیروهای تولید و برنامه نویس هستند چه برنامه نویس NET. و چه برنامه نویس Delphi.اما یک جای خالی داریم که چندین سال است دنبالش می گردیم و شخص مناسب را نیافتیم. افراد مختلفی را هم در این سمت امتحان کرده ایم که نتیجه مناسب نبوده است. این بار تصمیم گرفتم از طریق وبلاگ اعلام کنم، شاید کسی که می خواهیم را بیابیم. شخصی می خواهیم که بتواند فرآیند فروش نرم افزار را سازماندهی کرده و با کمک نیروهایی که در اختیارش قرار می دهیم، آن را برنامه ریزی و مدیریت کند.

قصد داشتم فقط یک آگهی استخدام بگذارم که نشد و باز چند خطی نوشتم!، جرقه نوشتن مطلبی هم خورد در زمینه سمت مهندسی فروش در شرکتهای نرم افزاری. به زودی در وبلاگ در مورد آن خواهم نوشت.

همین!

1- امشب دوشنبه است و از طریق رسانه های جمعی اعلام شد که سه شنبه عید فطر شده است و بالطبع تعطیل خواهد بود. عید شما مبارک.

2-با از طریق همان رسانه های جمعی اعلام شد که هیئت دولت، روزهای چهارشنبه و پنج شنبه را تعطیل اعلام کرده است. مبارک است !

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

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

همین!

بعد از نوشتار یا یادداشت شب عید: از تعطیلی بدست آمده استفاده کردم و بعد از دو سه سال، دستی به سر و روی وبلاگ کشیدم. بازهم می گویم تعطیلات فایده ندارد!

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

همین!

توضیح واضحات:
وبلاگ می نویسیم که بقیه بخوانند. در این شکی نیست. گفته ام که معتقدم به اینکه به "اشتراک گذاری اطلاعات قدرت است." (Sharing information is Power) 
سعی کرده ام که هر جا مستقیم یا غیر مستقیم از مطلب کسی استفاده کنم نامی ببرم از وی و لینکی بدهم به نوشته اش، چه داخلی باشد و چه خارجی.

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

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

همین!

"XP يا Extreme Programming در واقع يک فرآيند توسعه نرم افزار عميق و منظم مي باشد. اين روش از سال 1990 توسط شخصي به نام Kent Beck  به همراه  Ward Cunningham اين فرآيند را براي توسعه آسان نرم افزارها ايجاد و در سالهاي بعد آن را تکميل کردند به نحوي که از سال 1996 به عنوان يک روش مناسب کاربردهاي خود را نشان داد و هم اکنون در شرکتهاي مختلفي با سايز هاي متفاوت مورد استفاده مي باشد. يکي از دلايل موفقيت اين روش تاکيد آن بر رضايت مشتري است. اين متدلوژي براي ارائه چيزي که واقعا مشتري نياز دارد طراحي شده است. همچنين اين روش کمک مي کند که نيازهاي مشتري را حتي در پاياني ترين مراحل توليد در سيستم اعمال کنند. از ديگر تاکيد هاي روش توجه به کار گروهي است و اين کار را با ساده ترين و مؤثرترين راه انجام مي دهد.. مديران، مشتريان و توسعه دهندگان همه اعضاي تيمي هستند که مختص تحويل يک نرم افزار خوب (با کيفيت) ايجاد شده است.
XP يک پروژه نرم افزاري را در چهار وجه ، ارتباطات (Communication) ، سادگي (Simplicity) ، بازخورد ها (Feedback  ) و شجاعت (Courage ) بهبود مي بخشد: 1-برنامه نويس XP ابتدا با مشتري ارتباط بر قرار مي کند، سپس برنامه سازي را دنبال مي کند. 2- آنها طراحي خود را ساده و تميز نگه مي دارند. 3- با آزمايش نرم افزارهاي خود ار روز اول بازخورد مي گيرند. 4- سيستم را در اولين فرصت به مشتري تحويل مي دهند و تغييرات را به محض پيشنهاد دادن انجام مي دهند. بر پايه XP، برنامه نويسان قادر خواهند بود که شجاعانه به تغييرات نيازها و فنآوري پاسخ دهند.
XP شامل اجزا زیاد کوچکی است که در نگاه اول هر کدام معنی خاصی نمی دهد اما وقتی بایکدیگر ترکیب شدند یک تصویر کامل می سازند. این یک فاصله اساسی با توسعه سنتی نرم افزارها ایجاد می کند. در یک کلام XP متفاوت است."

مطلب بالا خلاصه است از ادعاهایی که طراحان XP در مورد روش خودشان مطرح کرده اند. در سلسله مطالبی، به مرور این روش خواهیم پرداخت.  سپس Agile را بررسی می کنیم  و به تغییرات اساسی که در فرآیند توسعه نرم افزار اعمال می کند اشاره می کنیم.

همین!

از روی اسم هم که شده ، مهندس نرم افزار باشی و سالها با شیء گرایی (Object Oriented) درگیر باشی: چه خوانده باشی ، بر مبنای آن برنامه نوشته باشی و یا بر اساسش تحلیل کرده باشی، بعید است اسم سه تفنگدار شی گرایی را نشنیده باشی، یکیشان همین جناب بوچ (Grady booch) . آنوقت خودت را جای من بگذار که تصادفا دنبال چیز دیگری می گشتم و وبلاگ این آقا را پیدا کردم. انصافا چه حالی پیدا می کنی!!؟
رو راست چهار، پنج دقیقه فقط داشتم با خودم کلنجار می رفتم که قبول کنم این اسم را درست می بینم یا نه، واقعا خودش است. عین آدمهای جن زده. نمی توانم بگویم مطالبش را خواندم، بهتر است بگویم برخی هایش را خوردم! این که یک نفر از جنس این آدمها (که نمی دانم چرا، ولی حس عجیبی نسبت بهشان دارم) را پیدا کنی که وبلاگ می نویسد و از خودش می گوید، حتی از مشکلاتش با بیمارستان و نمی دانم بازنشستگی جیمز رامبو (Jim Rumbaugh) از شرکت IMB.
شاید از نظر من این آدم ها نباید وبلاگ نویسی را جدی بگیرند. حداقلی خیلی از اساتید خودمان را که می دانم این کار را دون شان می دانند. آنوقت کسی مثل وی حتی زمانی که دارد به اتاق عمل می رود با کمک پرستارش جند خطی در وبلاگش بنویسد.
اگر دانشجو و یا فارغ التحصیل نرم افزارید و یا در این زمینه کار می کنید توصیه می کنم نگاهی به وبلاگ این آقا بیاندازید، در دوسایت IBM و BOOCH هم زمان به روز می شود. ضرر که ندارد هیچ، امیدوارم مثل من کیف هم بکنید. اگر هم نرفتید اشکالی ندارد ، در آینده اگر مطلب بدرد بخوری در این وبلاگ پیدا کردم خبرتان می کنم!

همین!

نوشته ای خواندم از آقای James M. Kerr  در سایت ComputerWorld . زیبا بود و مختصر. بد ندیدم ترجمه اش کنم و برای شما هم  بگذارم. ترجمه ای همراه با تلخیص. اصلش را بخوانید بهتر است. از من گفتن بود!

ده فرمان مدیریت پروژه
"آنها شرکت شما را به سمت سرزمین موعود فرهنگ مبتنی بر پروژه  (پروژه محور) رهنمون می سازند!"

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

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

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

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

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

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

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

8- از ابزارهای مدیریت پروژه استفاده کنید.
مدیریت پروژه های این دنیا را می توان خودکار نمود! بدنبال ابزارهایی باشید که پیگیری پروژه، مدیریت وظائف، مدیریت جریان کار و تحلیل نیاز به منابع را در یک بستر اینترانت که در آن به اشتراک گذاری اطلاعات و ارتباطات فراهم است را انجام می دهند. اما به یاد داشته باشید بهره گیری از فنآوری که یک لایه جدید از پیچیدگی را اضافه می کند در یک پروژه مشکل دار، ایده خوبی نیست.

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

10-کار گل (کثیف و سریع) را نپذیرد.
یک سیاست محکم مدیریت پروژه باید جلوی وسوسه مشارکت در پروژه های عجله ای و به دردنخور را بگیرد، زیرا فقط شما را به خطا، هدر دادن زمان ، دوباره کاری و ناامیدی رهنمون می کند.

همین!

قول داده بودم در ادامه مطلب اخلاق حرفه ای نظرات ACM/IEEE را ترجمه کنم و در این وبلاگ بگذارم که نشد. اجالتا به دلیل اهمیت این مطلب، خلاصه مورد به مورد این اصول را که در کتاب مهندسی نرم افزار آقای sommerville آورده شده است را ذکر می کنم:

اصول  مهندسی نرم افزار:
- مهندسین نرم افزار به نفع عموم کار می کنند(Public).
-مهندسین نرم افزار طوری عمل می کنند که به نفع کارکنان و مشتریان باشد و با نفع عمومی سازگاری داشته باشد. (Client & Employer)
-مهندسین نرم افزار تضمین می کنند که محصولات و اصلاحات آن ها از بالاترین استاندارد تخصصی پیروی می کند. (Product)
- مهندسین نرم افزارجامعیت و استقلال را در قضاوت تخصصی خود حفظ می کنند. (Judgement)
-مدیران و رهبران مهندسین نرم افزار، توسعه و نگهداری نرم افزار را بر اساس اصول اخلاقی انجام می دهند. (Management)
-مهندسین نرم افزار جامعیت و شهرت را مطابق با منافع عموم گسترش می دهند. (Profession)
- مهندسین نرم افزار حامی همکاران خود هستند و با آنها با عدالت برخود می کنند(Colleagues)
-مهندسین نرم افزار سعی در آموزش بیشتر در حرفه خود دارند و اخلاقیات را نیز رعایت می کنند.(Self)

همین!

بعد از نوشتار:خیلی وقت است که نشده که بنویسم، چرایش بماند. ترم جدید که شروع شد، فرصتش باز فراهم است.