اولین استخدام - پارت ۲ - آیا واقعا اولین استخدام مهمه؟

پارت قبلی راجع به این نوشتم که چرا اولین استخدام مهمه و به جوانب اهمیتش اشاره کردم. از پارت قبلی فیدبک‌های خیلی مفیدی از چند نفر از بزرگان حوزه‌های مختلف گرفتم که در نظر گرفتم که توی این قسمت و قسمت بعدی به اون‌ها هم بپردازم. توی قسمت‌های بعدی در نظر دارم همچنین به ساید کارمند هم بپردازم. فعلا برگردیم به موضوع این قسمت. تجربه خودم و چند نفر از دوستان از فرق شرکت نرم افزاری و سخت افزاری و شرکت B2B و B2C از نظر اهمیت اولین استخدام.

ماجرا از اونجایی شروع شد که شما یه کسب و کار دارین، کلی اضطراب و استرس توی کارتون هست که به قول هافمن، هم بنیان‌گذار لینکداین و سازنده پادکست masters of scale، انگار از یه صخره پریدین و باید در حین سقوط یه هواپیما بسازین که نجات پیدا کنین. اینجا شما می‌خواین قبل اینکه زمین بخورین، سریع هواپیما رو بسازین و شاید توانایی خودتون پاسخگو نباشه برای این و میاین یه تیم استخدام می‌کنین که توی این کار با شما همراهی کنن. به نظر میاد نفرات اول اون تیم بسیار مهمن و در ابعاد مختلفی آینده‌تونو تحت تاثیر قرار می‌دن. ولی اینجا یه نکته‌ای هست. نوع بیزنس و صنعتی که درش هستین. حرفم بیشتر برای بیزنس نرم افزاری B2C صدق می‌کنه و الآن می‌بینیم که چرا.

تمثیلی از اهمیت کیفیت محصول و مهندس‌های شرکت‌های سخت افزاری (تصویر با هوش مصنوعی DALL E ساخته شده)
تمثیلی از اهمیت کیفیت محصول و مهندس‌های شرکت‌های سخت افزاری (تصویر با هوش مصنوعی DALL E ساخته شده)

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

اولیش سرعت بسیار پایین iterationهای شرکت سخت افزاری و هزینه‌ی بسیار بالای مشکل (زمانی و مالی) بعد ریلیس شدن محصول هست. همون iterationهای sprint که ما تو شرکت نرم افزاری داریم و دو هفته‌ای‌ان مثلا و تهش حداقل یه فیچر ریلیس می‌شه دست کاربر، توی شرکتای اونا ۳ ماهه یا حتی بیشترن. چرا انقد بلند؟ نمونه‌ی علتشو توی شرکت‌های ماشین‌سازی و هواپیماسازی کلی توی اخبار می‌شنوین. مثلا داستان Boeing 737 Max و مشکلات عمده‌ای که منجر به این شد که شرکت boeing هزینه‌های سنگینی رو متحمل بشه. یا مثلا هر از گاهی می‌شه که یه شرکت ماشین‌سازی همه‌ی ماشین‌های یه مدل خاصش رو به دلیل یه مشکل فنی بازخوانی می‌کنه به کارخانه. همه این اتفاقا معمولا سر یه چندتا قطعه مشکل‌دار هستن که از فرایند‌های پیچیده و بسیار دقیق QA و QC اون شرکتا رد شدن و دست کاربر نهایی رسیدن. بعد شرکت برای اون پس گرفتن و اصلاح مشکل، کلی باید هزینه کنه. هزینه‌ای که قبلش احتمالا رفته برای رشد شرکت و آدمای جدید استخدام شدن و یه دفتر تو فلان کشور هم زده شده و برای شرکت سنگینه واقعا. برای همین تست شدن فیچر و دقت به همه جوانبش خیلی مهمه و معمولا بیشتر توی پروسه طراحی و QA و QC هستن محصولات طی این مدت چند ماهه و این امر مهندس‌های خیلی قدرتمند می‌خواد.

توی شرکت‌های نرم افزاری ما چی داریم؟ برای وب، دو هفته‌ای یه فیچر رو می‌زنیم، یه چند روز تست می‌شه و می‌رسه دست کاربر که بتونه اصن تست بشه ببینیم خود فیچر برای کاربر مناسبه یا نه. حالا چند نفر ممکنه به مشکلی بخورن، که سریع باگو پیدا می‌کنیم و توی نسخه بعدی برای اونا برطرفش می‌کنیم و هی طی زمان بهتر می‌شه. ولی اگه توی اپلیکیشن اندروید یا ویندوز باشه فیچر، حساس‌تر می‌شه چون نرم افزار دست کاربر می‌رسه و اگه مشکلی بخوره نیاز به بروزرسانی داره که دیده شده بیشتر کاربرا سمتش نمی‌رن خیلی اوقات. کاربر وقتی برای درست شدن مشکل مجبور باشه از اول نصب کنه یه چیزیو، خب می‌ره می‌گرده گزینه بهتر پیدا کنه اونو نصب کنه و ممکنه کاربر رو از دست بدین. این به نسبت شبیه‌تر می‌شه به اون فضای سخت افزار. ولی چیزی که توی نرم افزار خیلی مهمه، اینه که بتونیم اون سرعت ساخت فیچر‌ها رو داشته باشیم که به این برمی‌گرده چقد معماری کل سیستم خوب چیده شده. معماری سیستم اگه مشکل داشته باشه، بعدا شما ۴تا اسپرینت می‌ذارید که دوتا دونه فیچر ساده رو به سیستم اضافه کنید و وقتی یه میلیون کاربر دارید و کلی دولوپر، خیلی هزینه داره همچین زمانی رو گذاشتن. نیروی خوب و باتجربه آینده‌نگری داره و می‌تونه از اول جوری معماری سیستمو طراحی کنه که بعدا هم بشه روش سریع فیچر اضافه کرد و به اصطلاح future-proof باشه سیستم. برای همین اول کار خیلی مهمه مهندس باتجربه و قوی باشه. معمولا کو-فاوندر شرکت از این جنس آدما باشه ایده‌آله چون هم معمولا ماندگاره توی شرکت و هم بعدا لیدر نیروهای آینده می‌شه و می‌تونه بستر درستی توی تیم بسازه.

دومیش اون فضای B2B هست که برچسب‌های روی برند شرکت رو خیلی سنگین‌تر می‌کنه. توی شرکتای B2B، معمولا مشتریا با هم آشنان و توی محصولی که برای یه مشتری می‌فروشین حتی یه مشکلی پیش بیاد، همه باخبر می‌شن ازش و برند شرکتتون به شدت آسیب می‌خوره و احتمالا فروشتون توی محصولات دیگه به شرکت‌های دیگه هم ضربه می‌خوره. به علاوه نسبت به B2C طبیعتا کلاینت‌های کمتری با قراردادهای سنگین‌تر دارید شما و خب یدونه از ۴۰تا کلاینت مثلا دیگه باهاتون معامله نکنه خیلی بدتره نسبت به اینکه ۱۰ نفر از ۴۰۰ هزار نفر از محصولتون استفاده نکنن. همچنین بعضا این شرایط هم هست که اون قراردادهای اولی که دارین توی شرکت‌های B2B، معمولا یا مثلا آشنان یا ریسک‌پذیرترن که از یه شرکت جدید‌التاسیس دارن می‌خرن و لذا شاید حتی خیلی حساسیت به خرج ندن و دستتون بازتر باشه. البته که بعضا حساس‌تر می‌شن در این شرایط و همیشه اون حالتی که گفتم برقرار نیست حتی اگر ریسک‌پذیرتر باشن. توی این شرایط هم‌بنیان‌گذاری که مهندس قدرتمندی هم باشه خیلی می‌تونه کمک کنه که تا موقعی که استخدام‌های بعدی بیان، شرکت پا گرفته باشه.

توی فضای B2C، هم خبرا کندتر می‌پیچه و هم شما می‌تونین سریع‌تر باخبر بشین اگه محصول مشکلی داره و سریع حلش کنین چون استفاده‌کنندگان بیشتری دارین که هر کدومشون محصولتونو به نوعی دارن تست می‌کنن برای مشکلات مختلف و توی نسخه بعدی می‌تونین با هزینه کمتر از B2B این مسئله رو حل کنین چون هم اطلاعات بیشتری ازش دارین و هم سریع متوجهش شدین و زودتر دنبال راه حل رفتین. شانس بیارین چند نفر از کاربرا هم اصلا خودشون مهندسن و بهتون می‌گن چجوری حلش کنین و می‌تونین همش محصولو بهتر و بهتر کنین. ولی نکته‌ای که هست اینه که این امر توی نسخه‌های اول سرعتش کمتره چون مشتری زیادی ندارین. به علاوه می‌خواین نسخه‌های اول انقد خوب باشن که وایرال بشن و برندتونو جا بندازه.

در نهایت بنا به تجربه شخصی و دوستانی که توی این حوزه بودن، توی شرکت‌های B2B اون استخدام‌های اول نسبت به استخدام‌های بعدی اهمیت کمتری دارن و توی شرکت‌های B2C به نظر برعکسه. همچنین توی حوزه سخت افزار هم باز استخدام‌های بعدی مهم‌تر از استخدام‌های اولن و توی نرم افزار برعکس، اولی‌ها مهم‌ترن چون معماری محصول خیلی مهمه.

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