یک سال با یک استارتاپ

road curve

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

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

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

لیدر قبلی بیشتر کدهای مهم را خودش نوشته بود. تیم برنامه نویسی مشارکت زیادی در بازنویسی نداشته بودند. نتیجه این که بچه ها نمی توانستند یک سری جاهای پروژه را تغییر دهند. دلیل بعضی چیزها را نمی دانستند. یک اشتباه دیگر لیدر قبلی استفاده از تکنولوژی های خارج از رده در زمان شروع بازنویسی بود. همین یک قلم باعث شده بود در توسعه تیم به مشکلات اساسی برخورد کنیم، چون هیچ برنامه نویسی دوست نداشت با تکنولوژی های discontinue شده کار کند.

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

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

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

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

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

دعوای همیشگی front-end و back-end در تیم ما هم وجود داشت. گاهی اوقات ایرادی در نرم افزار به وجود می آمد که back به گردن front می انداخت و front هم به گردن back! تازه ما به جای یک front، دو تا داشتیم: یکی وب و دیگری موبایل. برای افزودن ویژگی ها هم همین داستان ها را داشتیم. رفت و برگشت بین استک ها طولانی و فرسایشی بود. نظر من این بود که در تیم به این کوچکی تفکیک وظایف را کمتر کنیم. به عبارتی دیگر، برنامه نویس های ما فول استک شوند تا مشکلات این مدلی کمتر شوند.

اما همه این کار ناامیدی و ناکامی نبود. قسمت های خوب هم داشت.

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

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

کلیت این کار برای خود من هم خیلی جذاب بود. چون کل کار زیر بار بود، challenge های زیادی برای من داشت که بیشتر این challenge ها هم همراه با یادگیری و کسب تجارب خوب بود. هم از نوع فنی و هم از نوع انسانی.

موفق باشید!

دیدگاه‌ها

  1. محسن خراسانی

    سلام آقای محبی . من یک سوال در مورد پروتکل ECE داشتم . اینکه عکس ها و یا فایل ها به چه صورتی در تگ های origin یا attachment ذخیره می شوند . آیا به آرایه ای از بایت ها تبدیل می شوند یا رمزنگاری می شوند در کل روند کار به چه صورتی است ؟

    1. نوشته
      نویسنده
      افشار محبی

      سلام. من خیلی وقته با این پروتکل کار نمی کنم. اطلاعاتم خیلی قدیمی هستش. ببخشید که نمی تونم کمک کنم.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *