با اینکه خیلی علاقه مند به نوشتنم ولی شاید سالی یکبار هم فرصت و حوصله ش رو پیدا نکنم. معمولا اینقدر سر خودمو شلوغ می کنم که وقت برای هیچکار دیگه ای ندارم. دعوت و پیگیری ویرگول از طرف #داتین به مناسبت روز برنامه نویس بهانه ای شد که بعد مدتها بنویسم. این سری می خوام در مورد چیزی بنویسم که تا حالا ننوشتم و فکر می کنم برای خیلی از برنامه نویس ها و فعالین حوزه کسب و کار جالب باشه.
یکی از کارهایی که خیلی پیش اومده انجام بدم نجات دادن بیزینسهاییه که دچار مشکلن. مشکل ممکنه در جذب سرمایه، مدل کسب و کار، کندی در رشد، زیرساخت و فنی و ... باشه ولی امروز چون روز برنامه نویسه منم در مورد کیس هایی می نویسم که به دلیل مشکلات زیرساختهای نرم افزاریشون در آستانه ورشکستگین. آخرین موردش یه شرکت کانادییه که بعد از دو سال توسعه نه تنها نتونسته بودن محصول جدیدشون رو عرضه کنن بلکه هیچ نشانی ای هم از قابل استفاده بودی چیزی که تیم توسعه شون بهشون تحویل داده بود نبود.
معمولا شرکتهایی که توی این شرایط هستن، زمان و هزینه قابل توجهی رو از دست دادن و گزینه های زیادی برای حل مشکلاتشون ندارن. طبیعتا وارد چنین کاری شدن و پذیرفتن مسئولیت احیای کار بسیار دشواره و حداقل به تجربه من هرچقدر هم که انجام بدی بازم دشواره. جدا از اینکه توسعه نرم افزاری که یک کسب و کار روش بنا میشه به تنهایی کار بسیار پرچالشیه، بیزینس هایی که توی این وضعیت هستن مشکلات متعدد دیگه ای هم دارن.
فشار رقبا به خصوص در کشورهایی که رقابت واقعی وجود داره واقعا جدیه. در یک بازه زمانی حتی کمتر از ۶ ماه ممکنه همه چیز تغییر کنه. هزینه های اداره شرکت و نیروها هم که خوب معمولا هم جا سنگیه و امکان ادامه فعالیت اگر درآمدی نباشه تقریبا غیر ممکنه. البته در این مورد خاص شرکت در حوزه فعالیتش خیلی با سابقه بود و حداقل مشکل بیزینسی نداشتن.
معمولا اولین کاری که می کنم اینه که بررسی می کنم ببینم میشه از تیم فعلی و خروجی که تا اون موقع داده استفاده کرد یا نه. اینجا جاییه که پیش داوری و تعصب می تونه به قیمت خیلی گرونی تموم بشه. طبیعتا دور انداختن و از نو انجام دادن، هم خیلی جذاب تره و هم راحت تر. اینکه بگیم چون یکی دیگه کارو زده پس حتما بده هم می تونه به اون کسب و کار آسیب بزنه. دعوای بهترین فریم وورک و زبان برنامه نویسی هم جایگاهی نداره.
وقتی یک پروژه یا کسب و کاری به مشکل می خوره، مشکل همیشه مشکل مدیریته. در این مورد هم انتخاب نا مناسب تیم توسعه و برنامه ریزی اشتباه باعث دو سال اتلاف وقت و انرژی شده بود. معمولا کسب و کارهای که تازه وارد حوزه IT میشن در اولین تجربه به چنین وضعیتی گرفتار میشن.
در این مورد تیم توسعه نتونست گزارش درستی از وضعیت کار بده و مشخص بود که حتی تعریف نیازها هم مشکل داشته و نیاز هست که همه مستندات تکمیل و سازماندهی بشه. شانسی که آوردن این بود که پلتفورمی که استفاده شده بود مناسب بود و ضرورتی به تغییرش نبود در نتیجه میشد حداقل بخشی از کدی که نوشته شده رو استفاده کرد و بعدا سر فرصت اصلاحات اساسی تر رو اعمال کرد. تیم توسعه ولی توان فنی اجرای چنین کاری رو نداشت و باوجود اینکه نرم افزار کار نمی کرد تمایلی به پذیرفتن و اصلاح ایرادات نداشتن در نتیجه مجبور شدم همرو اخراج کنم و تیم جدید بیارم.
همونطور که گفتم کار مشکلات مدیریتی جدی داشت و به دلیل ناآشنایی تصورات مدیر عامل با واقعیت های صنعت تطابق نداشت. طبیعی بود که روی برنامه زمان بندی و بودجه هم مشکل باشه. به تجربه من، حداقل زمان برای توسعه یک نرم افزار و رسوندنش به وضعیت production حداقل 6 ماه زمان میبره. به ندرت زودتر از این قابل انجامه. علتش البته فقط بحث های فنی و کمبود نیرو نیست. برای توسعه محصول موفق خیلی کارهای دیگه هم لازمه انجام بشه که زمان بره و در طول این 6 ماه ممکنه انتظارات تغییر کنه که طبیعیه. در این مورد علاوه بر پلتفورم جدید، پلتفورم قدیمی هم به موازات باید توسعه و نگهداری میشد که طبیعتا منابع زیادی فقط برای همون مورد نیاز بود.
مستندات تکمیل شدن، بررسی فنی کار انجام شد، پلن فنی و غیر فنی تهیه شد، نیروهای استخدام شدن، تیم جدید مستقر شد، آموزش های تیم داده شد، روندهای توسعه و کنترل پروژه تدوین شد و کار توسعه شروع شد. یکماه قبل یعنی بعد از ۸ ماه اولین نسخه پایدار نرم افزار آنلاین شد و فروش روی پلتفورم جدید رو شروع کردن.
کار توسعه محصول نرم افزاری کار بسیار دشواریه. برای رسوندن کار به مرحله ای که هم نیازهای ضروری کسب و کار رو برطرف کنه و هم قابل اطمینان باشه خیلی خیلی خیلی باید تلاش کرد. خیلی از فرضیات اشتباه می تونن باعث نابود شدن یا آسیب های جدی به کسب و کار بشن. تجربه من این بوده که عمده ایرادات اساسی مربوط به مشکل در معماری نرم افزاره پس باید خیلی جدی گرفتش و همیشه باید فرض رو بر این گذاشت که صرف نظر از اینکه چقدر تست کردیم نرم افزار هنوز باگ داره ولی ما نتونستیم همرو پیدا کنیم (حتی اگر تست خودکار هم داشته باشیم) پس باید روندها و ابزارهای مناسب در اختیار داشته باشیم که اگر مشکلی پیش اومد بتونیم به سرعت و دقت هم مشکل رو برطرف کنیم و هم اگر اطلاعاتی از بین رفت بتونیم بازیابی کنیم.
توسعه نرم افزار می تونه یک هنر باشه. روز همه برنامه نویس های پرتلاش و خلاق و هنرمند مبارک :)
