شکاف عمیق عدم وجود سیستم های نرم افزاری - این قسمت تیم های نرم افزاری

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

حالا در این پست تصمیم دارم به تیم های نرم افزاری بپردازم و دلایلی رو مطرح کنم که متاسفانه اکثر مدیران شرکت های نرم افزاری بهش دقت نظری ندارند .

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

مدیران سازمان باید چه چیزی رو ببینند ؟

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

چرا؟؟؟

این حرکت جدید مستلزم چه چیز هایی هست؟
چرا شرکت های نرم افزاری نمی توانند به این سمت حرکت کنند و دائما یک کار تکراری رو انجام میدن و به همین درآمد عادی خودشون راضی هستند( چون اگه راضی نبودند در جهت تغییر اون یک اقدام متفاوتی می کردند)

خوب راه حل چیه؟
تا اینجا که همش سوال مطرح کردیم.
چه باید کرد؟:متفکر:

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

آیا در فضای کاری که این افراد باهم کار میکنند صمیمیت هست یا دائما زیرآب همدیگه رو پیش مدیر شرکت میزنند؟

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

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

مورد بعدی اینکه در تیم های نرم افزاری چند درصد افراد کارهای خودشون رو انجام میدن؟
مثلا ظرفهای خودشون رو بشورن یا بتونن باهم چای دم کنند یا زباله هارو جمع کنند بدون اینکه نیازی به مستخدم یا آبدارچی باشه؟
بدون شک هیچی. حداقل من ندیدم.
خوب وقتی ما نمیتونیم برای کارهای روزمره خودمون یک پروسه ثابت درنظر بگیریم و کارهای خودمون رو انجام بدیم و دائما انتظار داریم یک نفر سومی بیاد همه کارهای مارو انجام بده شاید ما دوخط بتونیم کد بنویسیم٬ اونوقت چه انتظاری میره که بتونیم نیازهای یک سازمان عریض و طویل با مثلا ۲۰ هزار کارمند رو انجام بدیم.؟
آیا میتونیم برای روند کارهای اونها راهی رو پیشنهاد بدیم؟

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

متاسفانه در فرهنگ ما ٬ دادن اطلاعات به همدیگه ٬ صحبت کردن باهم ٬ بیان اشکالات همدیگه ٬‌تعارف نکردن ٬ نیازمون رو صریح درخواست کردن یک جورایی ظاهرا عیب حساب میشه که همین باعث شده تاثیرات خیلی عمیقی در کار و کیفیت محصولاتمون گذاشته.

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

دوست دارم در این زمینه نظرات شما عزیزان رو هم بشنوم و از تجارب شما استفاده کنم.

ایام به کام./

اگر منظور شما کیفیت نرم افزار هست:

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

۲. دیدگاه درست: توی ایران به شکل عجیبی داخل کشور دیدگاه درستی از نرم افزار وجود نداره و بازهم ۹۹ درصد اون بر می گرده به اینکه اکثر برنامه نویسها اطلاعات درست ندارن. یه برنامه نویس واقعی باید در مورد خیلی چیزها اطلاعات داشته باشه. شما نمی تونید از کسی که فقط یک یا دو زبان برنامه نویسی رو طی یکی دو دوره آموزشی و یا کتاب یاد گرفته انتظار ساخت و یا درک درست از نرم افزار داشته باشید.

۳. اصول اشتباه: توی ایران باور خیلی بزرگی وجود داره که شما باید از اصول مهندسی نرم افزار و چه می دونم اصول پایگاه داده استفاده کنید. در صورتی جالبه که بدونید اکثر شرکتهای خارجی مواردی این چنینی رو رعایت نمی کنن و بجاش برنامه نویس با تجربه استخدام می کنم یادم میاد یه ایرانی آمریکایی که شرکتش نرم افزارهای چندین شرکت از جمله تویوتا رو تهیه کرده بود رو دیدم ازش پرسیدم شما چی کار می کنید گفت روش آبشاری (حالا به نصف این فروم بگی آبشاری می خندن) یا همینطور یک ایرانی آلمانی که رو توی شرکتها بزرگ آمریکایی هم کار کرده بود دیدم اون هم دقیقا توی یک کلمه گفت آبشاری و بعد گفت مگه روش دیگه ای می شه؟!!! درستش اینه که اکثر مواقع نه پتانسیل کافی و نه زمان کافی برای پیاده سازی روشهای کتابی نیست و بجاش باید برنامه نویس های با تجربه استخدام بشه و اونها در کمترین زمانه ممکن همه چیز رو مشخص کنن و فورا برن روی کد. مثلا همون آمریکایی می گفت من ۱۵ تا برنامه نویس خبره دارم که باهاشون جلسه می زاریم محیط کار رو می بینیم و بعد فورا شروع می کنیم به کدینگ. روش های این چنینی برای پروژه های خیلی خیلی خیلی بزرگ که مثلا در اوراکل و شرکتهای این چنینی در طی چند سال پیش برده می شه جوابگو هست.


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


اگر مشتری رو می گید:
بزرگترین مشکل مربوط به حیطه بازار یابی هست. شما بازار یابهای زیادی رو می تونید داخل کشور پیاده کنید اما حتی ۱۰ درصد از اونها هم موفق نیستن. دلیل بزرگش اینه که بیشتر بازاریابی تجربه محلی هست و نه مواردی که در دروه های بازاریابی و مربوط به اون مثل دورهای MBA و DBA درس داده می شه. بازار یابی کامل لوکال (local) هست و شما نمی تونید با کتابهایی که داخل آمریکا یا انگلیس نوشته شدن بازار یابی کنید.

"
مدل آبشاری یک مدل ترتیبی توسعه و تولید نرم‌افزار است و درآن مراحل تولید به شکل یک جریان مداوم متمایل به سمت پأيین است.
( همانند یک ٓابشار‌ )
که شامل فازهای تحلیل خواسته‌ها، طراحی، پیاده‌سازی یا implementation، آزمودن و تست کردن، یکپارچه سازی یا integration و دادن محصول به بازار می‌شود.
اغلب گفته می شود ریشه ی اصطلاح آبشاری از مقاله‌ای گرفته شده است که توسط Winston W.Royce در سال ۱۹۷۰ نوشته شده است.
مدیریت و مراحل تکمیل پروژه در این متدولوژ‌ی به سادگی قابل پیاده‌سازی است. زیرا در مرحله اول که مرحله بررسی نیازمندی های پروژه می باشد، مشتری و تیم برنامه نویسی طی چند جلسه به بررسی نیازمندی ها و خواسته‌های پروژه می پردازند. سپس پس از ٓان نوبت به مرحله طراحی می رسد، در مرحله ی طراحی افراد طرح کلی پروژه را می ریزند و جزییات پیاده‌سازی مشخص می شود. پس از مرحله ی طراحی تیم برنامه نویسی خود را برای پیاده‌سازی ٓاماده می کند. در این مرحله همه قسمت های کد, پیاده‌سازی می شوند. در انتهای این مرحله, ما مرحله یکپارچه سازی یا integration را خواهیم داشت یکی از مشکل ترین قسمت های انجام پروژه‌ها در این مرحله می باشد زیرا تنوع و گسترده‌گی کار کامل در این مرحله نقش دارد.
هر چه میزان گستردگی کار بیشتر باشد به همان انداره سختی یکپارچه سازی نیز بیشتر خواهد بود.


مزیت آبشاری:
1-فهم این مدل ساده تر است.
2-از نظر تولید مستندات بهتر هستن.
3-مراحل قابل کنترل و بررسی هستن.


معایب آبشاری:
1- کار تیم های پایانی موکول به اتمام کار تیم های ابتدایی می باشد.
2-بررسی بازخور سیستم توسط کاربران نهایی دارای پروسه مجزا و در انتهای کار می باشد.
3- گذر از مراحل بصورت نوبتی و وقت گیر می باشد.
"

*************************************

به نظر من این مدل و روش عملکرد تنها روش کاربردی و قابل پیاده سازی به صورت گروهی هست.

نقل قول:

---

1- کار تیم های پایانی موکول به اتمام کار تیم های ابتدایی می باشد.

---

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

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

اکثر شرکتها قدرت درک تغییراتی رو که برنامه نویسهای حرفه ای (بهتر بگیم توسعه دهنده) می تونن براشون ایجاد کنند رو ندارن. دیدگاه اونها در کوتاه مدت ممکن هست که باعث شه کل روند طراحی نرم افزار و ... در شرکت متحول بشه اما در بلند مدت سرعت توسعه و کیفیت به مراتب بالاتر میره.

سلام حمیدرضا جان

بنظر من یکی دیگه از مشکلاتی که گریبان گیر جامعه آی تی ایران هست؛ نبود فرهنگ knowledge sharing هست. وقتی کسی حاضر نیست دانش خودش رو به دیگری یاد بده و کمکش کنه که کار ها رو با کیفیت بالاتر انجام بده؛ چون میترسه که ممکنه همکارش برای خودش شاخ بشه. اینطوری میشه که همه با هم رقیب میشن بجای رفیق. همه میخوان دیگری پیشرفت نکنه چون خودشون ضایع میشن. همه میخوان زیرآب دیگری رو بزنن که حتی اگه همکارشون از نظر فنی بهتر از خودشون باشه.

در کل؛ اگه فرهنگ به اشتراک گذاری دانش در میان ما کارمندان بخش آی تی فراگیر بشه؛ فرهنگ کار تیمی خودبخود درست میشه و کیفیت کارها میره بالا و شرکت ها بیشتر به موفقیت نزدیک میشن. مطمئنا مایکروسافت و گوگل و آمازون و اپل با زیرآب زنی به اینجا نرسیدن.

متشکرم
فرشید
:چشمک:

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

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