چند وقت بود که بحث تیم یا گروه در بسیاری از وبلاگهایی که مطالعه می‏كردم، مطرح مي‏شد و خواندن آنها هم برايم جالب بود و هم آموزنده.
براي بيان تفاوت بين تيم و گروه، حكايتي را به مضمون نقل مي‏كنم كه خواندنش خالي از لطف نيست:
“حكايت مي‏كنند كه ده نفر در كارواني در راهي مي‏رفتند. دو دزد به كاروان زدند و تا مي‏توانستند، كتكشان زدند و هر چه داشتند، بردند. كسي از آنجا مي‏گشت، پرسيد: چگونه اين اتفاق افتاد كه شما ده نفر بوديد و آنها دو نفر.
يكي از آن ميان گفت: آنها دو نفر بودند، همراه و ما ده نفر بوديم، تنها. “
آن دو نفر، تيم بودند و آن ده نفر، گروه.

گزيده:
“مورچگان را چو فتد اتفاق شير ژيان را بدرانند پوست” سعدي

نظرات دوست خوبمان، آقای مهندس نگاهی درباره درد مشترک جالب و خواندنی است. قضاوت با شما.

1- به نظر من کم سواد ( یا بی سواد ) تا زمانی که هیچ چارچوبی در قوانین کشور ما وجود نداشته باشد که از تولید کننده بیچاره نرم افزار حمایت شود هیج راهی ب سرمنزل مقصود نمی رسد
2-جایی که Intel دیگر cpu نمیسازد در آمریکا و Microsoft به سراغ سیستم عامل تحت satelite میرود ، دیگر مجالی برای حرکت تدریجی نیست .
3- اما اینم باید در نظر گرفت در صنعت نرم افزار ما مدیری که یک رهبر باشد نداریم تا بتوانیم یک حرکت سریع کنیم پس همان لاک پشت بار پیشکشمان ، اگر هم داشته باشیم قدرت ندارد و اگر قدرت داشته باشد ، قانونی نیست که از آن حمایت کند
4- زمانی که وزیر IT میگوید اینترنت 56K برای مصرف خانگی و بری دانشجویان کافی است دیگر باید منتظر حرکت تدریجی ماند
5- اگر ما در نرم افزار کم تجربه هستیم دنیا که اقیانوس تجربه است ، چرا هند بزرگترین تولید کننده نرم افزار است، چرا ما هیشه باید آزمون و خطا کنیم ؟؟
6-هنگاهی که یک فرد معمولی هوس میکند برنامه نویس بشود و با خرجی معادل 8000 تومان برای خرید یک VS و یک کتاب ادعای برنامه نویس حرفه میکند و اسم خودش را میگذارد مهندس ، باید چکار کرد

نتیجه : جور دیگر باید زیست

گزیده:
«موانع»، آن چيزهاي وحشتناکی هستند که وقتی چشمتان را از روی هدف بر می‌داريد، به نظرتان می‌رسند. هنری فورد

با تشکر از عزیزانی که در هم‏اندیشی موضوع “درد مشترک” شركت كردند، ادامه نظرات دوستان را در زير آورده‏ام.

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

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

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

گزيده:

پس از نوشتن مطلب درد مشترک به نقل از وبلاگ رادمان، آقای ابوذر نوذری پیشنهاداتی در این زمینه ارائه داده‏اند كه ضمن تشكر از ايشان، پيشنهاداتشان در ادامه آورده شده است:

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

• آغاز یک حرکت نرم و تدریجی در راستای تغییر دیدگاه در تولید نرم افزار از رویکرد استادکاری به رویکرد مهندسی

مطلب زیر از وبلاگ رادمان نقل شده است:

«این روزها فرصتی فراهم شده است که با چند شرکت متوسط و بزرگ نرم افزاری از نزدیک آشنا شوم، نه آنطوری که خود را برای مشتریان خود نمایش می دهند، آنگونه که واقعا هستند. مواجه شدم با یک “حقیقت ساده” انکه سایز شرکتها هر چقدر هم که باشد گویی با یک سری مشکل مشابه مواجه هستند:
1- مشکلات ناشی از سرمایه ناکافی که قدرت ریسک را از شرکتها می گیرد.
2- بزرگ شدن بدون آنکه الزامات بزرگی را رعایت کرده باشند و خود را برای آن آماده کرده باشند.
3- مشتریانی که همیشه ناراضی هستند
4- مشکلات مدیریت نیروی انسانی که گویی کسی که بتوان بیش از یک سال رویش حساب کرد دیگر به سختی یافت می شود.
5-نداشتن دید مالی و بازرگانی نزد مدیران شرکتها و قوی تر بودن وجه فنی این افراد
6- مظلومیت تولید کنندگان نرم افزار که حاصل دسترنجشان به کمترین هزینه فروش می رود در حالیکه مشتری بابت سخت افزار همان نرم افزار چندین برابر هزینه می کند.
7- عدم وجود و یا کارآمدی قوانینی که حقوق این شرکتها را در مقابل تکثیر غیر قانونی نرم افزارشان، ترک کار نیروهایشان و سرقت اطلاعات طراحی سیستمهای آنها حفظ کند.
8- رقابت ناسالمی که برخی همکاران غیر حرفه ای ایجاد می کنند.
9- وابستگی شدید اقتصاد کشور به دولت که با کوچکترین نوسانش بزرگ و کوچک شرکتها هم آسیب می بینند و عدم توانایی رقابت واقعی با شرکتهای خارجی در خارج از مرزها
10- و در آخر همان حکایت کوزه گر و کوزه شکسته، نبود سیستمها و نرم افزارهای مناسب در شرکتها برای مکانیزه کردن فرآیندها در این شرکتها چه در سطح داخلی و چه در سطح مديريت روابط مشتريان»
شاید بتوانم 90 تای دیگر هم به این نکات اضافه کنم. مواردی که همه فعالان این صنعت همه می دانند و هر یک به نوعی درگیر آن هستیم، اما چاره چیست؟ نظر شما در این زمینه کدام است؟
در مورد اصلاح ساختاری شرکتهای نرم افزاری برای توانمند سازی آنان در مقابل مشکلات و دشواری ها مطلب خواهم نوشت. اما پیش از آن مایلم تجربیات شما را در این زمینه بدانم.
همین!

گزیده:
به عوض آنکه به تاريکی لعنت بفرستيد، شمع روشن کنيد. «کنفوسيوس»

یادآوری: نويسنده محترم به دنبال روشن كردن سهم خود از شمعهاست كه جاي سپاس و قدرداني دارد.

• Attempting too much, too fast, too soon.
• Abandoning good software engineering practices.
• Adopting a technology or methodology without well-defined objectives.
• Picking the wrong horse.
• Underestimating the resistance.
• Not educating and enlisting management before the fact.
• Asking the wrong questions.
• Confusing approach with results.
• Betting the company on a given technology or methodology.
• Getting on the feature release treadmill.
• Not recognizing the politics of architecture.
• Getting religious about the technology or methodology.
• Overselling the technology or methodology.
• Confusing prototypes with finished products.
• Confusing training with skill.
• Confusing tools with principles.
• Confusing buzzwords with concepts.
• Thinking a new technology or methodology will solve all your problems.
• Thinking a new technology or methodology comes for free.
• Adopting a new technology or methodology for the wrong reason.

Reference: http://bfwa.com/pitfalls

: عيب کار اينجاست که من «آنچه هستم» را با «آنچه بايد باشم» اشتباه مي‌كنم. خيال مي‌كنم آنچه بايد باشم هستم، در حاليكه آنچه هستم نبايد باشم. «آندره‌ژيد»

من به كسي كه آرزويي براي آموختن ندارد، تعليم نخواهم داد. همچنين هيچ مطلبي را براي كسي كه خود در جستجوي درك آن نيست، توضيح نخواهم داد. كنفوسيوس

از پيشگفتار كتاب «آموزش تفكر انتقادي» از «چت مايرز» ترجمه دكتر خدايار ابيلي

گزيده: اگر بناست كه يادگيري شاگردان تحقق يابد، آنها بايد كتابها را كنار بگذارند، جزوات خود را بسوزانند و جزئيات از بر شده براي امتحان را فراموش كنند. آلبرت نورث 1929