کمبود برنامه‌نویس و راهکار مقابله با آن
پای درد دل هر مدیر شرکت نرم‌افزاری که بشینی میبینی یه مشکل اساسی پدرشو درآورده؛ «آقا برنامه‌نویس نیست!»
بعد یه نگاه که میندازی، میبینی از سر و گوش شرکتش داره نیرو میریزه؛ پس چته مؤمن؟
دقیق‌تر که بشیم تازه متوجه میشیم که مشکل ایشون کمیت برنامه‌نویساشون نیست، با کیفیت مشکل داره. راحت بگم، کیفیت برنامه‌ها و محصولاتش به دلش نمی‌شینه. البته خود آقای مدیر که اینو نمی‌دونه، نارضایتی مشتری‌هاش پوستشو کنده و فهمیده که هم تغییرات به موقع انجام نمیشن و هم ایرادات به‌درستی رفع نشدن.
توی این مقاله میخوام یکی از چرخه‌های مدیریت پروژه که تاحالا خیلی بهم کمک کرده رو باهاتون به اشتراک بذارم.
توی تیم‌های کوچیک و چابک، روند انتقال نیازها و درخواست‌های کارفرما به تیم برنامه‌نویس به صورت مستقیم و یا حداکثر یک واسط در قالب منشی یا خود مدیرعامل انجام میشه. این مساله باعث میشه مشکلاتی از قبیل عدم درک دقیق و کامل درخواست و عدم پیگیری انجام درخواست و به هم‌ریختگی الویت‌ها خودشو بیشتر نشون بده.
توی همچین سیستمی هرمشکلی که پیش بیاد –مثلا کارها دیر برسه، باگ‌ها زیاد بشه و ...- اولین کاری که مدیریت انجام میده اینه که آگهی استخدام برنامه‌نویس بزنه. میزنه ولی چنتا مشکل پیش میاد، یکی اینکه یه برنامه‌نویس تا بیاد پروژه رو بفهمه حداقل چند هفته طول میکشه و تازه وقت برنامه‌نویس‌های دیگه رو هم برای آموزش و توضیحات پروژه میگیره. مشکل بعدی هزینه‌ی بالاییه که برنامه‌نویس برای سازمان ایجاد میکنه هم حقوق بالاتر و هم سیستم و تجهیزات مورد نیازش. مساله‌ی بعدی اینکه نیرو متخصص مورد نظر هم به‌سختی پیدا میشه و یه شبه نیست این پروسه. و امان از روزی که بعد از این همه انرژی و وقت و هزینه میبینی انگار اونقدر هم که فکر میکردی پروژ‌ت پیشرفت نداشته و به فکر اضافه کردن یه برنامه‌نویس جدید میوفتی.
برنامه‌نویس جدید هم تقریبا مثه همیشه میگه که کدهای قبلی فایده نداره و باید بازنویسی بشه!
به‌نظرم عنصر اصلی تیم برای تنظیم الویت‌ها و زمان‌بندی و پیگیری کارها مدیرپروژه‌اس. این عزیزدل باید از EQ (هوش هیجانی) نسبتا بالایی برخوردار باشه و بتونه با تیم به‌خوبی ارتباط برقرار کنه. اگه تا الان همچین نیروی دقیق، منضبط و خوش‌اخلاقی رو توی تیمتون نداشتید، مشکلی نداره فقط باید بدونید که اولش تیم فنی به شدت مقاومت میکنه. توی مقاله‌های بعدی بیشتر راجع به شخصیت و وظایف مدیرپروژه و نحوه‌ی تزریقش به تیم صحبت میکنیم.
پس یعنی از اینجا به بعد کارفرما به هیچ وجه با تیم فنی مستقیما ارتباط نمی‌گیره و این وظیفه‌ی مدیرپروژس که کارها رو به تیم فنی بده و ازشون سر زمان مقرر تحویل بگیره و بده به مشتری.
وای بر شمایی که این پاراگراف رو جدی نگیرید!!
تاحالا هیچ پروژه‌ای رو ندیدم که بدون تیم تست باشه. همیشه گفتم که تستر شما یا توی تیمتونه یا بیرون تیمتون؛ امان از روزی که تستر بیرون تیم و یا به نوعی همون مشتریتون باشه. هر باگی که پیدا میکنه یه گل به خودی و یه تیر زهردار به سمت تیم فنی و حتی فروش شماست.
راحت بگم، ما برنامه‌نویس‌ها تا ببینیم کدمون یه بار جواب میده فکر میکنیم که دیگه شاخ غول رو شکوندیم و وقتشه که یه پپسی(یا هرچی دوست دارین) برا خودمون باز کنیم. اما مهره‌ی کلیدی که الان معرفیش می‌کنم، وظیفش رصد همیشگی عملکرد کل سیستمه (نه فقط یک بار، اونم تو محیط آزمایشگاهی).
تضمین کیفی یا Quality Assurance نیروییه که از چند منظر فعالیت‌های تیم فنی رو از نظر کیفیت، کنترل و ارزیابی میکنه: ظاهر برنامه، ورودی‌ها، خروجی‌ها، بررسی فرآیندها و یه عالمه کار جذاب دیگه که حتما توی مقاله‌های بعدی راجع بهش می‌نویسم.
تستری که الان نیاز تیممون رو برطرف میکنه الزاما فنی نیست و کافیه که نگرش نقادانه داشته باشه و یه‌کم وسواسی باشه، بتونه مو رو از ماست بکشه. فارغ‌التحصیل‌های رشته صنایع برای این سمت میتونن گزینه مناسبی باشن. هم ویژگی‌های جدید رو از نظر عملکرد بررسی میکنه و هم تغییرات و خرابی‌هایی که با اضافه شدن ویژگی‌جدید ایجاد شده رو گزارش میده. برای پیشرفت هم کافیه یه کم UX یاد بگیره. باید ارتباط تنگاتنگی با تیم فنی داشته باشه ولی معمولا خودش تسک و ایرادات رو به برنامه‌نویس‌ها برنمیگردونه و گزارشش رو به مدیر پروژه میده تا ایشون راجع به الویتش تصمیم بگیره.
خوندن ادامه‌ی این مطلب به افرادی با مشکلات قلب‌و‌عروق و فشارخون بالا توصیه نمیشه!
حالا فرض کنیم که تموم تیم‌هایی که گفتیم کار خودشونو به خوبی انجام دادن و کار به موقع و با کیفیت به دست مشتری عزیزتر از جان رسید.
ترسناک‌ترین فیدبک و جمله‌ای که میشنویم اینه که مشتری میگه: «این چیه؟ من که این منظورم نبود!!!»
وات؟!؟
و لامصب «حق همیشه با مشتریست.» شانسش گفت.
خیلی واضحه که نگاه مشتری نسبت به خواستش با نگاه برنامه‌نویس نسبت به موضوع متفاوته یا حتی کیلومترها فاصله داره و برای حرف زدن باید یه مترجم بین این دو عزیز باشه؛ حرف‌های کارفرما قطعا نیاز به تفسیر داره، حتی بعضا خود کارفرما هم نمی‌دونه چی میخواد! میگه من یه سایت میخوام و تمام. راستش برنامه‌نویس‌ها درسته خیلی باهوشن ولی هنوز به قابلیت نیت‌سنجی و ذهن‌خوانی مجهز نشدن (ایشالا آپدیت بعدی).
پایه‌ای‌ترین مهره‌ای که باعث جلوگیری از هدر رفت انرژی تیم میشه، مدیر محصوله. مهارت اصلیش شامل ارتباط خوب با کارفرما و درک مشکلاتیه که محصول، به هدف حل اونا به‌وجود اومده. برای شروع هر پروژه‌ای این مدیرمحصوله که به‌دنبال پیدا کردن نیازمندی‌ها و فرآیندها به صورت دقیقه. در ادامه، فعالیتش به مرحله آزمون پذیرش محصول تغییر میکنه. در کل مدیرمحصول توی تمام مسیر و مراحل پروژه حواسش به اینه که همه‌ی نیازهای کاربر و کارفرما رو تامین کنه. به این مهره بعضا Business Analyst یا تحلیل‌گر کسب‌وکار هم میگن، کسی که مسئول شناسایی نیازهای کسب‌وکار مشتریان و ذینفعانه و با هدف رفع این نیازها و مشکلات، راهکارهاش رو ارائه میده.
این چرخه‌ای که الان باهم بررسیش کردیم یکی از ساده‌ترین و درعین حال کاربردی‌ترین چرخه‌های مدیریت تولید و توسعه محصولات نرم‌افزاریه. میخوام یک بار برای همیشه این پرونده رو توی ذهنتون ببندید، مشکلات شما توی شرکتتون با استخدام برنامه‌نویس حل نمیشه، همین الان هم بهترین‌هاشون رو دارید و این همه دانشجوی کامپیوتر مستعد که میتونن به این اکوسیستم وارد بشن؛ مشکل پروژه‌های شما توی اون حلقه‌های مفقوده‌ای که بهش اشاره کردم پنهان شده. از امروز اگه هم خواستید آگهی استخدام بزنید اول از همه یه مدیرپروژه و بعدش یه تستر به تیمتون اضافه کنید. BA هم اگه ندارید که فاتحتون خونده‌س.
