وقتی به اکثر شرکت های نرم افزاری نگاه می کنیم ، عموماً با مدیرانی روبه رو می شویم که سابقاً تمامی سمت های اجرایی در یک شرکت مهندسی نرم افزار را طی کرده و امروز پس از کسب تجربیاتی در حوزه برنامه نویسی ، تحلیل و طراحی ، مدیریت پروژه ، مالی و اداری ، منابع انسانی و … امروز مسؤولیت فروش یا مدیریت عاملی شرکت های خود یا شرکت هایی که در آن مشغول به کار هستند را بر عهده گرفته اند.
به جز معدود شرکت های بزرگ و نسبتاً موفقی که مدیران آنها به جای برنامه نویسی توان تحلیلی بزرگی در حوزه کسب و کار خود داشته اند ، این داستان ، داستان تکراری همه شرکت هاست.
مدیرانی که تنها تجربه خود را در تولید می بینند . کسانی که در همه شرایط با تفکر اینکه اگر محصول ما دارای فلان خصوصیت یا بمان خصوصیت باشد حتماً می توانیم شرکت ایگرگ را به جمع مشتریان خود اضافه کنیم ، همواره در تلاش برای اضافه کردن یک جزء جدید به پازل پیچیده خصوصیت های قبلی نرم افزار شان هستند .
شاید شما هم تجربه کرده باشد و در مواجه با نرم افزارهایی که چندین سال از ورود آنها به بازار و فروش به تعداد زیادی مشتری گذشته است ، حتماً در هنگام کار کردن با سورپرایز های جدیدی رو به رو شده اید که عموماً ناشی از ذهن پیچیده یک برنامه نویس یا تحلیل گر است که به احتمال زیاد در هیچ یک از جلسات آموزشی ( به شرط برگزاری ) یا مستندات راهنما ( به شرط به روز بودن) شما ردی از آنها نخواهید دید و حتی در تماس با پشتیبانی شرکت ها هم ممکن است با این جمله رو به رو شوید که ” جداً چنین اتفاقی رخ میده !” .
اما به نظر شما این مشکل ناشی از کجاست ؟ از خواسته های مشتری ، از خواسته های تیم تحلیل ، از روش های پیاده سازی تیم برنامه نویس و یا از یک نقطه تاریک دیگر در حوزه مدیریت مالی شرکت های نرم افزاری.
من به شخصه اعتقاد دارم ، مشکل اساسی از حوزه مدیریت مالی و حوزه تدوین استراتژی در شرکت های نرم افزاری است. در نوشته قبلی با عنوان “فرق کلوچه سازی با توسعه نرم افزار” اشاره ظریفی به هزینه های توسعه محصول شده بود و این اشاره جرقه این ایده برای من شد که اصل مشکل از نداشتن بهای تمام شده خدمات در شرکت های توسعه دهنده نرم افزار است.
وقتی شما به عنوان یک مدیرعامل ، مسؤولیت اجرایی یک شرکت یکصد نفره را بر عهده دارید ( فرض کنید شرکت های کوچک تر هم در همین مقیاس با ضرایبی کمتر درگیر مشکل هستند) تنها به حقوق پرسنل ، لیست بیمه ، اجاره و هزینه های جاری در آخر هر ماه ، اظهار نامه های مالیاتی در تیرماه و عیدی و سنوات آخر سال می اندیشید و تنها شاخصی که می تواند جبران کننده این ردیف هزینه ها در شرکت شما باشد ، شاخص عددی فروش نرم افزار یا خدمات شماست که دائم از تیم فروش می گیرید. اگر از شانس بد شما ، بازار انتخابی تان هم بازار دولتی باشد احتمالاً با شاخص عددی تراز مطالبات از هر مشتری و نهایتاً سرجمع این عدد نیز رو به رو هستید.
توجه به کمینه سود در صنعت نرم افزار که جای خود دارد و ترجیح می دهم در یک موقعیت دیگر در مورد رابطه سود دهی و حفظ کارایی در عملکرد پرسنل و تصمیمات استراتژیک شرکت صحبت کنم. ولی مدیر عاملی که در مقابل این همه ردیف هزینه تنها یک ابزار فروش دارد ، مسلماً به جای تصمیم گیری و دقت در برآورد هزینه ها متمرکز بر روی فروش می شود و اولین بازخوردهای تیم فروش از مشتری اول و دوم و سوم باعث می شود که راساً دستور توسعه خصوصیات جدید را در محصول ارائه دهد و عملاً چرخه “تولید بیشتر ، فروش بیشتر” را شروع می کند.
اگر یک مدیر می توانست هزینه های مستقیم و غیر مستقیم توسعه هر خصوصیت جدید در محصول را دیده و بر اساس عملکرد تیم تولید ، اثرات جانبی آن را تخمین بزند شاید هیچ وقت درگیر این بازی دو سر باخت نمی شد. چرا که هم با این کار تعدادی از مشتریان راضی خود رابه مشتری ناراضی تبدیل می کند ( فرض کنید زمان توسعه بر نحوه کیفیت پشتیبانی مشتریان دیگر تأثیر مستقیم داشته باشد و یا اینکه در حالتی که محصول تک ویرایش باشد ، خصوصیتی برای مشتری می رود که احتیاجی به آن نداشته و یا کارایی یا روش کارکرد سیستم را دچار تغییر کرده است) و هم هزینه های بسیار زیادی در حوزه آموزش تیم فروش و پشتیبانی شرکت ، بازآموزی مشتریان قبلی ، تغییر ذهنیت کاربران فعلی سیستم و نهایتاً به روز رسانی کلی از مستندات تحلیلی و آموزشی محصول را به وجود خواهد آورد.
در این بین به این پیش فرض هم توجه کنید که تمامی این تصمیمات منجر به یک سناریوی صحیح تولید شامل استناد به تحلیل تجربیات مشتری ، طراحی کاربردپذیر ، پیاده سازی با کمترین اثرات روی سایر قسمت های برنامه و … باشد .
شاید در فرصت دیگری به ارتباط مهم تفکر چابک و توسعه اسکرام در ساختار تیم های نرم افزاری با روش برآورد صحیح از بهای تمام شده خدمات بپردازم و بتوانیم بیشتر در مورد این مزایا صحبت کنیم ولی تا همین جا هم ، به مدیران عامل یا مدیران توسعه محصولی که با فشار تیم های فروش رو به رو هستند یک پیشنهاد دارم .
قبل از پذیرش خواسته آنها برای یک خصوصیت جدید در نرم افزار ، حتماً از آنها بپرسید بدون این خصوصیت ، شرکت ایگرگ مشتری محصول ما نخواهد بود ؟ مطمئن باشید این خواسته در هشتاد درصد مواقع با پافشاری شما روی ارتباط مجدد تیم فروش با مشتری کاندید ، به حذف درخواست خواهد انجامید.
باور کنید بسیاری از خصوصیاتی که به نرم افزارها با این رویه اضافه می شوند ، هیچگاه توسط مشتری مورد استفاده قرار نخواهد گرفت .
به جای این کار روی شاخص اصلی بهای تمام شده خدمات تیم خود در شرکت تان تمرکز کنید و گلوگاه های اصلی هزینه و کاهش سود شرکت خود را شناسایی کنید. مشکل نقدینگی و حاشیه سود پایین ، در مدیریت اشتباه شما در تصمیمات نهفته است.
خوبه ، به هر حال تیم همیشه سرمایه اصلی شرکت های نرم افزاری بوده اند و تمرکز روی تیم هدف نهایی رو نشونه می گیره . مطلب خوبی بود