خبر همین بود: "تصویب سند راهبردی IT در هیات دولت". (اصل خبر را در ایسنا بخوانید، اینجا)، به اندازه کافی این خبر حس کنجکاوی و پرسش را در من زنده کرد که بدانم سندی که 1200 نفر ساعت کار در کمیته علمی و 21 هزار نفر ساعت کارگروه های تخصصی شورایعالی فنآوری اطلاعات  روی آن گذاشته شده است، چیست؟ از سوی دیگر به عنوان یک شاغل در صنعت نرم افزار و حوزه فنآوری اطلاعات کشور هم این سند می تواند جهت گیری آینده حرکت ما را نیز روشن کند، اما ...

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

همین!

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

-زمان پارامتري بسيار مهم در شرکت هاي نرم افزاري است. چه در رعايت زمانبندي پروژه اي خاص براي يک مشتري و چه در توليد يا ارتقاء نسخه جديد و در فضاي رقابتي و سرعت در اختصاص سهم بازار به محصول خود. در بسياري از مرراد افزايش بهره وري مي تواند راهکار خوبي در تسريع فرآيند ها گردد.
- رخداد خطا و نيز ريسکهاي پروژه جزئي جدا نشدني از پروژه هاي نرم افزاري هستند، برخلاف برخي صنايع که پس از توليد و تست، محصول تا پايان مدت عمر مفيد آن کمتر دچار خطا خواهد شد، يک محصول نرم افزاري دچار خطاهاي طراحي و پياده سازي متعدد، خطاهاي ناحيه بحراني (Critical rigens) هستند که به همراه تغيير در نيازها و شرايط محيطي باعث مي شود در يک پروژه نتوان مديريت خطا و ريسک را ناديده گرفت.
- کوچکي شرکتهاي نرم افزاري در مقابله با ساير صنايع: شرکتهاي نرم افزاري کشور اغلب با نيروي انساني زير 50 نفر فعاليت مي کنند و در شرکتهاي کوچک نيز با نيروي زير 20 نفر، پروژه ها را برعهده مي گيرند. کم نگه داشتن تعداد نيروي انساني که به سبب جلوگيري از رشد بادکنکي شرکت هاي نرم افزاري به عنوان يک عامل کليدي و مهم در نزد مديران شرکتهاي نرم افزاري مطرح مي شود باعث مي شود که با يک تعداد کم نيرو، پروژه هاي بزرگ و متعدد گرفته شود. اينجاست که ورودي ثابت است و خروجي نياز به بزرگ شدن دارد. تنها راه چاره در اين موارد افزايش بهره وري است.
- ...

بهره وري بايد در يک شرکت نرم افزاري موارد زير را نتيجه دهد:
- کاهش زمان توليد
- کاهش خطاهاي محصولات نرم افزاري
- افزايش رضايتمندي مشتري از طريق حذف تاخير ها و خطاهاي نرم افزاري
- کاهش هزينه هاي جاري شرکت
-کاهش تنش ها و اختلافات ناشي از پروژه ها

برخي موارد کليدي تر در افزايش بهره وري در شرکتهاي نرم افزاري بر اساس حوزه عملکرد آنها -در يک نگاه اوليه- عبارتند از:

بخش توليد:
- بکارگيري متدولوژي هاي استاندارد در چرخه تحليل تا نصب و ارزیابی نرم افزار
- بکارگيري ابزارهاي مهندسي نرم افزار (CASE Tools) در ساخت سيستم
- افزايش روحيه کارگروهي در بين بخش هاي فني با اجرايي طرح هايي نظير Pair Programming
- اجراي سياست پلکاني در آموزش نيروي انساني
- مديريت کد برنامه و بکارگيري ابزارهاي مناسب در جهت حفظ و مديريت سورس کد برنامه
- بکارگيري برنامه هاي تست (Test Plan) و ابزارهاي تست خودکار برنامه ها (Test Program)
-مستند سازي فرآيند توليد و بکارگيري روشهاي مناسب در جهت افزايش قابليت گسترش و قابليت استفاده مجدد در محصول ها
- جذب نيروي هاي مناسب و مستعد براي افزودن به بخش هاي فني مختلف
-...

بخش پشتيباني:
- تست پيش از نصب نرم افزار
-بکارگيري روشهاي مناسب در آموزش قطعي کاربران سيستم
- تهيه مستندات آموزشي و راهنماهاي مناسب
- قطعه بندي نرم افزار براي ارتقاء ساده تر آن
- بکارگيري سياست هاي نسخه بندي (Versioning) در برآورده سازي نيازهاي مشتريان
- بکارگيري ابزارهاي Remote براي پشتيباني راه دور
- مستند سازي تست و آزمايش نرم افزاري براي جلوگيري از بروز خطاهاي مشابه در نرم افزارهاي آتي
-...

بخش فروش:
- ايجاد مستندات نمونه براي پيشنهاد هاي پروژه (Document Template)
- حرس کردن مشتريان و حذف مشتريان و حوزه هاي غير مؤثر
- برگزاري جلسات مؤثر در معرفي و دموي محصول (جلسات جامع و مانع)
- عدم گرفتن پروژه به هر قيمتي و قبول پروژه هاي مساله دار (کار گل!)
- ارائه مستندات به صورت آنلاين
- مديريت وقت و پيگيري مداوم مشتريان (استراتژي پيگيري فروش)
- رعايت سياست قيمت گذاري مناسب براي فروش محصولات به بخش هاي مختلف
-جذب نمايندگي در شهرستانها و گسترش شبکه هاي فروش براي محلي سازي فروش از يکسو و گسترش حوزه پوشش فروش از سوی دیگر
-...

موارد بالا همگي جنبه ابتدايي داشته که در نگاه اول به نظر مي رسد و مطئمنا با يک نگاه دقيق تر و اندکي تامل بيشتر -که اين روز ها شديدا دنبال وقتي براي آن مي گردم!- مي توان اين فهرست را کامل تر کرد (اميدوارم خواننده محترم خود نظر خود را در اين مورد ارائه نمايد تا فهرست کامل تر شود)

همين!

پیشتر نظرخودم را راجع به کپی کردن یک مطلب بدون ذکر منبع آن گفته بودم (اینجا).اما ...
تا جاییکه این اتفاق در بین وبلاگ ها و وب سایت های شخصی بیافتد دلخوری زیادی باقی نمی ماند، اما وقتی واحد مرکزی خبر (IRIB) هم، به عنوان یک بنگاه اطلاع رسانی و خیر رسانی حرفه ای،  مشمول این قاعده بشود چه باید گفت!؟
اینکه نوشته ای را بدون ذکر مرجع و منبع کار کنند در قواعد کار حرفه ای اطلاع رسانی مطمئنا کار درستی نیست. نوشته" 15 دليل برای ميوه فروش شدن به جای مهندس نرم افزار شدن" را که چند ماه پیش نوشته بودم(اینجا) را در IRIBNews پیدا کردم (http://www.iribnews.ir/Default.aspx?Page=ScienceContent&news_num=131956) و تعجب کردم از این که... خودتان می دانید.
همین!

نوشته ای با همین نام "بررسی انواع رویکردهای دولتمردان به IT " را در پایگاه تحلیل فنآوری اطلاعات بخوانید (اینجا)

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

همین!

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

همین!

در قسمت سوم مطالب "شرکت فوتبالی، فوتبال شرکتی" (قسمتهای 1و 2) به نوع و تفاوت سیستم بازی خواهم پرداخت. ابتدا تعریف "سیستم بازی" :
این یک تعریف دقیق و علمی نیست، اما فکر می کنم سیستم بازی به نحوه چیدمان بازیکن های فوتبال در یک تیم و شعاع حرکتی آنها می پردازد. سیستمهایی نظیر 3.5.2 یا 4.4.2 فکر می کنم سیستمهایی معروف هستند که امروزه استفاده می شوند، 3.6.1 - 3.4.3 - 4.3.2.1 - 4.3.1.2  و .... سیستمهایی هستند که یا یک تیم فوتبال بر اساس آنها بازی می کند و یا یک مربی در هنگام بازی های مختلف و بر اساس نوع حریف و نیاز بازی آن را تغییر می دهد.
اما ارتباط سیستم بازی با یک شرکت نرم افزای چیست؟
اگر یادتان باشد بخش فروش یک شرکت را در خط حمله، بخش تولید را در خط هافبک و بخش پیشتیبانی را در خط دفاع نگاشت دادیم. با قابل قبول دانستن این نگاشت و نگاه به سیستم بازی خودتان می توانید تغییرات را حس کنید.
در مورد برخی شرکتها که توان فنی بالاتری دارند اما نیروهای فروش خوبی ندارند و یا سبک کارشان اجرای پروژه های اختصاصی است که نیازی به یک فرایند دائمی و جدی فروش ندارند (به عنوان فروش محصول) می توانند سیستمی نظیر 3.6.1  را انتخاب کنند که در بخش هافبک (نیروهای تولید) میانه میدان را در اختیار دارند و دل به تک گل (گرفتن یک پروژه خوب توسط فروش) بسته اند و پس از گل زدن با توان مضاعفی که در پشت زمین دارند نتیجه را حفظ می کنند.

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

ذکر چند نکته را بر اساس انتخاب سیستم بازی برای یک شرکت نرم افزاری مهم می دانم:
- اگر سیستم 3.6.1 را انتخاب کرده اید دنبال یک مهاجم گل زن بگردید (یک مدیر فروش خوب) که اگر آن را پیدا نکنید، خوب بازی خواهید کرد (چون توان فنی بالایی دارید) و همه کار خواهید کرد الا گل زدن! کی بازی را خواهید باخت که به قول یک جمله همیشگی از مربیان بازنده "اگر گل نزنی، گل خواهی خورد"
-دقت کنید در همه سیستمها، پشتیبانی خالی نیست، بنابراین به عنوان یک مربی همیشه بخش پشتیبانی خود را در حد مناسبی نگه دارید و تقویت کنید .
- تلاش کنید در حد توان و استطاعت مالی و فنی روی نیمکت ذخیره های خود، افرادی که توانایی بازی در یک یا چند از خطوط را داشته باشند را جذب کنید تا در صورت بروز خطا و یا یک ریسک نیروی انسانی تعویض به موقعی انجام دهید و گرنه در موقع بروز خطا یا ریسک سعی کنید سیستم بازی را تغییر دهید، برای مثال اگر یک گل سه امتیازی زدید ، حریص نباشید، سیستم بازی را عوض کنید و به لاک دفاعی بروید تا این امتیاز را حفظ کنید.
- دقت کنید در یک گروه بازی فقط گل زدن مهم نیست، گل نخوردن هم مهم است. اگر 3 یا 4 گل هم بزنید ولی نتوانید آنها را حفظ کنید بازنده خواهید شد بنابراین سیستم خود را طوری انتخاب کنید که در هر سه لایه نفرات داشته باشید. دیده ام شرکتی که 0.9.1 چیده است و یا 0.3.6 که فایده ای ندارد و در طول بازی موفق نخواهد بود (به قول مربیان ایرانی بازی احساسی!) از سوی دیگر بازی فقط تدافعی هم چاره کار نیست، نمی شود با یک امتیاز از هر مسابقه (تساوی) قهرمان شد.
- داشتن نیروهای فوق العاده در شرکت مانند بازیکنانی ستاره در زمین ، تضمین کننده برد نیست. داشتن مارادونا خوب است اما اگر دیگر نبود چه، اگر این بازیکن گل برند و بقیه تیم راه بروند چه، اگر مصدوم شد چه؟ بنابراین تلاش کنید ابتدا یک تیم قوی از متوسط ها بسازید بعد اگر بودجه یا شانسش را داشتید، یک ستاره هم جذب کنید تا در هنگامی که کارتان گیر کرد از خلاقیتش استفاده کند تا شما را نجات دهد.
- در خط دفاع، پشتیبانی دفترتان سعی کنید از نیروهای باتجربه استفاده کنید و یا خودتان به نحوی عمل کنید که چگونه خطوط نظم پیدا کنند. (در مورد ساختار دفاعی و ساختار حمله در یک شرکت نرم افزاری خواهم نوشت.)
ادامه دارد...
اگر کسی این مطلب را بدون سابقه ذهنی در مورد مطالب قبلی بخواند، احتمالا این وبلاگ را با یک کلاس مربیگیری فوتبال اشتباه خواهد گرفت!!

همین!

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

"سلام خسته نباشید
من ......  هستم دانشجوی رشته عمران اب و فاضلاب یک مقاله در مورد نگهداری و تعمیرات پیشگیرانه در شبکه فاضلاب می خواستم ممنون می شم اگه به من کمک کنید

تشکر"

شما به جای من، کجای این وبلاگ به عمران آب و فاضلاب ربط دارد!؟
همین!

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

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

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

همین!

سال 82 تصميم گرفتيم  که آرمان ، ماموريت و اصول ارزشي رادمان را تدوين کنيم. يکي از اصول ارزشي که با تبادل نظر با همه بچه هاي شرکت تعيين شد، اين عبارت بود "پروژه جاري، اولويت اول زندگي من است"
توضيح اينکه در زماني که پروژه اي گرفته شد، به آن احترام بگذاريم و به عنوان اولويت اول در کار و زندگي نگاه کنيم به شکلي که کارهاي با اولويت پايين تر را به پس از پايان پروژه و يا در زمان هاي خالي بين وظائف پروژه موکول کنيم. چرا؟ چون در مهندسي نرم افزار-همانند همه رشته های کاربردی- اصلی مهم وجود دارد "مشتري مداري" که با عباراتي نظير "هميشه حق با مشتري است" ، "تا پايان پروژ به مشتري لبخند بزنيد" و .... بيان می شود. تلاشمان بوده است که با همين شکل با مشتري و نيازهايش برخورد کنيم ،به اولويت هاي زماني اش و بايد ها و نبايد هايش احترام بگذاريم، در برخي جاها موفق بوده ايم در تحقق اين هدف و برخي جاهاي ديگر هم خير.اگر بخواهم توضيح بيشتري بدهم بايد مقداري از نحوه کار شرکت را در بخش توليد بيان کنم. در رادمان گروه توليد را به دو بخش تقسيم کرده ايم:
- پيشاني تيم يا frontend : که وظيفه شکافتن و جلو بردن يک پروژه توليد را بر عهده دارند.
- عقبه تيم يا Backend : که وظيفه تکميل کد ها، ايجاد ماژول هاي ثانويه و بهبود طراحي واسط کاربري را بر عهده دارند.
اين دو گروه را از روي برنامه نويس "روزکار" يا "شب کار" انتخاب کرده ايم که قبلا در موردش صحبت کرده ام.(اینجا)
چرا؟

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

همين!

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

همین!

پی نوشت : در نوشته ای قدیمی، گفته بودم که برخی وقت ها چقدر حسرت آن را می خورم که ایکاش یک برنامه نویس ساده بودم، که چه کار لذت بخشی است برنامه نویسی و تولید. (اینجا)

پيشتر ها وقتي تفاوت توليد صنعتي با توليد نرم افزاري مقايسه مي شد، يکي از دلايل سودآوري بيشتر توليد نرم افزاري را در آن مي دانستند که در توليد صنعتي يک بار توليد مي کني، يک بار مي فروشي، اما در توليد نرم افزاري يک بار توليد مي کني، n بار مي فروشي. اينکه هزينه تکثير محصول نرم افزاري آنقدر پايين است که مي توان آن را نسبت به هزينه اوليه ساخت ناديده گرفت.
اما ...
اين روزها، اين قاعده را بايد به فراموشي سپرد. چرا؟ چون در اغلب محصولات تخصصي،   نمي توان يک محصول را در اختيار همه قرار داد، مگر آنکه عموميت مساله، حجم فروش و انحصاري بودن بازار آنقدر باشد که بتوانيد با رعايت يک الگوي ورژن بندي، براي پوشش نيازهاي مشتريان ، در يک روش تکاملي محصول را ارتقاء داد.
در مسائل جديد نرم افزار و در بازارهاي اختصاصي تر و يا با وجود رقباي زياد، شما به عنوان يک توليد کننده نرم افزار مواجه خواهيد شد با مقداري از منطبق سازي، که خود يک پروژه کوتاه مدت جديد خواهد بود و باعث تغيير در نرم افزار شما مي شود. به دلايلي که ذکر کردم گاهي اوقات دست شما بسته است که به مشتري بگوييد همين است و بس.
براي مثال در مورد سيستمهاي مالي اداري، با وجوديکه محصولات پر فروشي مانند سيستم هاي همکاران سيستم در بازار وجود دارد، اما به دليل تغيير نگرش کاربران و استفاده کنندگان، که ترجيح مي دهند هر چقدر کم، آنقدر در نرم افزار تغيير داده شود که احساس کنند آن نرم افزار اختصاصي براي خودشان است و نياز واقعيشان را برآورده مي کند، سراع توليد کنندگان کوچکتر و محصولات کمتر رايج اما در عين حال پويا تر مي روند.مي بينم که شرکتهاي کوچک حتي در تبليغاتشان، اينکه نرم افزار را اختصاصي مي کنند را به عنوان يک مزيت مطرح مي کنند و در پرسش خريداران ، قابليت اختصاصي شدن نرم افزار با نيازهاي آنان هم به عنوان يک عامل تاثير گذار در تصميم گيري مطرح مي شود.

اگر بخواهم نگاه دقیق تري به مساله اختصاصي سازي نرم افزار داشته باشم بايد مروري بکنیم بر سير تحول توليد محصول نرم افزاري:
- در دوره هاي اول به دليل نيازهاي کم و رشد نيافته بودن تکنيک هاي مهندسي نرم افزار، هر مساله يک پروژه جديد بود و حجم فروش دوباره محصولات بسيار پايين بود.
- با رشد نيازها و وضع تکنيک ها، روشها و فرآيند هاي توسعه نرم افزار، مساله توليد يک بار، فروش چند بار از طريق ساخت بسته هاي نرم افزاري (Software Packages ) عام رواح پيدا کرد و توليد کنندگان، مصرف کننده را ملزم به استفاده از همان محصول ثابت مي کردند. مشتريان هم به دليل عدم تنوع در انتخاب ناچار به پذيرش اين واقعيت بودند.
- با بلوغ تکنيک هاي توسعه نرم افزار و افزايش سطح توقعات مشتريان، ديگر نمي شد محصول را بدون منطبق سازي مطرح کرد، اما تلاش مي شد اين منطبق سازي در حجم کم و يا در قالب نسخه هاي بعدي (Next Version ) حل و فصل شود.
در اين دوره با ساخت سيستمهايي نظير ERP تلاش شد همه فرآيند هاي سازمانها استاندارد و پياده سازي گردد تا يک محصول يا بخشي از آن بتواند نياز يک مشتري جديد را برآورده سازد، اما باز هم بحث Tailoring را براي منطبق سازي محدود سيستم با نياز هاي مشتري مطرح است و رايج. چنانچه مي بينيم متدولوژي هاي تحليل و طراحي سيستمها نيز به سمت روشهاي قابل انعطاف تري مانند متدولوژي هاي چابک (Agile) مانند روش برنامه سازي کرانه اي (XP) حرکت کرده اند که پذيرش تغيير از جانب مشتري را به عنوان يک اصل مي شناسند.

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

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

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

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

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

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

همین!

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

همین!