وبلاگ افشار محبی

شغل مهندسی نرم افزار یک جور به خصوصی است که باعث می شود خیلی راحت از مسیر خودش خارج شود. خیلی از مهندسین نرم افزار، به خصوص اونهایی که در حوزه نرم افزارهای مالی اداری کار می کنند، بعد از چند سال کار تبدیل می شوند به یک Business Analyst. در واقع به جای این که نگران Performance، امنیت یا قابلیت نگهداری نرم افزار باشند، صرفا نگران Business Logic و گردش کار نرم افزار هستند. شاید به همین دلیل است که تولید کنندگان نرم افزارهای Line of business مثل همین نرم افزارهای مالی اداری، بیشتر کاربران MS SQL ، اوراکل و اکسس هستند تا برنامه نویس. منظور من این نیست که این ابزارها به درد نخور یا کم اهمیت هستند، بلکه اینها در دسته بندی کاربری ابزارهای IT هستند نه کد نویسی به شکل متعارف آن. خیلی از این دست تیم ها، عمده منطق تجاری را از طریق اسکریپت های SQL انجام می دهند که برنامه نویسی حساب می شود ولی نه این مدلی که مهندسین نرم افزار به خاطرش چند سال به دانشگاه می روند.
خیلی از مهندسین نرم افزار در ادامه این مسیر به Domain Expert تبدیل می شوند. یعنی تبدیل می شوند به رفرنس صنعت در یک حوزه خاص. شاید در آگهی های استخدام دیده باشید که استخدام کننده به دنبال مهندس نرم افزار با تجربه کار در یک حوزه به خصوص می گردد. این یعنی آن شرکت به دنبال متخصص در آن بیزنس به خصوص می گردد و حداقل در این بخش از تعریف شغل به دنبال یک مهندس نرم افزار واقعی نمی گردد.
در تقریبا ده سال اخیر که ادبیات اجایل و اسکرام رایج شده، می بینیم که مسیر بعضی از مهندسین نرم افزار این بار به سمت Product Owner بودن و طراحی محصول منحرف شده است. نیاز سنجی مشتری، پایش بازار و طراحی محصولی که بتواند نیازمندی ها را جواب گو باشد، کاری حیاتی و فوق العاده با ارزش است. اما به عقیده من، که خیلی هم مخالف دارد، کار مهندسی نرم افزار تازه از اونجایی که طراحی محصول کامل می شود، شروع می گردد. یک مهندس نرم افزار مسئول پیاده سازی محصول است نه حدس زدن این موضوع که دکمه کوچک پایین صفحه برای استفاده راحت تر است یا دکمه باریک سمت چپ صفحه.
درست است، کاملا هم درست است: اگر نقش تحلیل گر و طراح محصول را از بعضی مهندسین نرم افزار بگیریم، دیگر کار زیادی برای آن مهندس نرم افزار نمی ماند که انجام دهد. این موضوع اصلا غلط نیست.چینش آن تیم است که باید اصلاح شود. برای تحلیل سیستم از اولش هم باید از یک مهندس صنایع، یک حسابدار یا یک کارشناس مدارک پزشکی آشنا به نرم افزار نویسی استفاده می شد نه یک مهندس نرم افزار. اصولاً کاری را که یک فرد بدون داشتن تجربه برنامه نویسی هم می تواند انجام دهد را نباید به یک برنامه نویس سپرد. بعضی از کارهای تحلیل سیستم و طراحی محصول را هر فرد متوسطی با چند سال تجربه کار می تواند انجام دهد و لزومی هم ندارد که این فرد یک مهندس نرم افزار باشد.
به عنوان یک قاعده تجربی اگر دیدید که توی یک تیمی هیچ خبری از اصول نرم افزار و مسائل رایج آن نیست، شک کنید که مهندسین نرم افزار آن تیم مشغول کارهایی خارج از حوزه واقعی مهندسی نرم افزار هستند. حتی می توان در این موضوع هم بحث کرد که علت کم سوادی مهندسین نرم افزار ما و تفاوت زیادی که بین توسعه نرم افزار در ایران و خارج از ایران وجود دارد نیز موضوعات مشابه این دست انحرافات است.
.
.
.
.
کل این متن را با تبلت در حالی که در سالن انتظار یک مرکز درمانی منتظر بودم نوشتم.