اگر در بازار توسعه نرم‌افزار و مهندسی آن باشید، احتمالا شما هم زیاد با این دوراهی برخورد کرده‌اید که کار در یک شرکت زیرساختی و پروژه‌ی B2B را انتخاب کنید و یا وارد کارزاری هیجان‌انگیز از برخورد مستقیم خروجی کارتان با کاربران نهایی و عموم مردم شوید.
مساله‌ای که در این یادداشت می‌خواهم به آن بپردازم مقدمه‌اش را در لینکداین نوشتم:
صورت مساله به نظرم واضح است. چطور می‌توانیم در یک شرکت که هدف‌گذاری محصولاتش فروش به کسب و کارهای دیگر است و نه الزاما عموم مردم، به تیم و کارکنان انگیزه لازم برای کار را بدهیم؟
کارکنان و توسعه‌دهندگان در این پروژه‌ها همواره این سوال را از خود می‌پرسند که اگر در تیم فلان نرم‌افزار موبایل که برای مثال ۱۰ میلیون کاربر دارد، کار می‌کردند، بهتر نبود؟ آیا آنجا چیزهای بیشتری یاد نمی‌گرفتند؟ مسائل و مشکلاتی که در آن پروژه‌ها وجود دارد چیست؟ رزومه‌ی کاری من پس از کار در این محصول که نامش در هیچ‌جایی نیست چه می‌شود؟ سوال‌هایی از این دست در کنار همان مشکلات ذکر شده در صورت مساله، باعث می‌شود انگیزه همکاری در این شرکت‌ها به مرور در بین کارکنان تنزل پیدا کند و در واقع نگهداشت نیروی انسانی ماهر و توانمند در این محصولات سخت‌تر و سخت‌تر شود.
در ادامه کمی در مورد گام‌ها و روش‌هایی که می‌توان برای بهبود این شرایط و افزایش انگیزه توسعه‌دهندگان برای فعالیت در این محصولات به کار برد، می‌نویسم.
در برخی از تیم‌های با محصولات زیرساختی، به دلایل مختلف، فرآیندهای حرفه‌ای توسعه و انتشار محصول نادیده گرفته می‌شوند. از ابزارهای قدیمی برای نگهداشت و یا مدیریت پروژه استفاده می‌شود و سرعت استفاده تیم از محصولات حاشیه‌ی توسعه نرم‌افزار، همچون ابزارهای مدیریت مخازن کد و یا خودکارسازی روال آزمون و انتشار، بسیار کند و در برخی مواقع ناچیز است.
تعریف یک فرآیند حرفه‌ای توسعه نرم‌افزار با روال‌های صحیح از تعریف صورت مساله، اعمال زمان‌بندی در رسیدن فعالیت‌ها، روال‌های شفاف بررسی کیفیت کد، الزامی بودن پیاده‌سازی آزمون‌های سطح واحد برای کد، مستندسازی دقیق، استفاده از ابزارهای خودکارسازی روال انتشار و ایجاد مراحل مختلف انتشار محصول از جمله مواردی است که می‌تواند فضای تیم را حرفه‌ای نگه دارد و اطمینان کافی را به توسعه‌دهندگان بدهد که آن‌ها در محیطی بسیار حرفه‌ای و حتی حرفه‌ای‌تر از محصولات کاربرمحور، فعالیت می‌کنند.
چیزی که اندازه و کاربرد یک پروژه‌ی زیرساختی را به رخ می‌کشد نه تعداد خط کد آن و یا طراحی کلاس‌ها و توابع، بلکه شمایی واقعی از آن‌چیزی است که در نهایت برای محصول شما اتفاق می‌افتد. توسعه‌دهندگان با دیدن یک تصویر بزرگ از آن‌چیزی که در کل محصول در حال وقوع است و اجزای مختلف آن به صورت شماتیک، یک دید سریع از اهمیت کار خود پیدا می‌کنند. چیزی که در محصولات کاربرمحور بسیار شفاف است و نیاز به شرح و بسط طولانی و عجیبی ندارد.
نمایش جایگاه خروجی هر تیم در سبد محصولات و یا محصول بزرگ‌مقیاس، ارزش مادی و معنوی‌ای که این خروجی تولید می‌کند و سایر مواردی از این دست، در قالب‌های جذاب بصری می‌توانند هیجان اولیه کافی‌ای برای کارکنان تازه‌وارد ایجاد کنند و توسعه‌دهندگان قدیمی را نیز از اهمیت کار خود مطمئن کنند.
مستندات معماری در سطح کلان به همراه نمودارهای سطح جز که اجزای کلی یک سامانه زیرساختی را نمایش دهد و وظیفه هر جز را به صورت قبل فهمی تعریف کند، می‌تواند توسعه‌دهندگان را نسبت به آنچه در حال وقوع است هوشیار کرده و دقت عمل کارکنان را بالا ببرد.
مهم است که توسعه‌دهندگان بدانند اگر کار آن‌ها نباشد در عمل چه اتفاقی خواهد افتاد؟ اینکه برای مثال «ما امنیت دیجیتال شرکت‌ها را تامین می‌کنیم» حتما جمله‌ی شفاف و قانع‌کننده‌ای برای یک توسعه‌دهنده روساخت وب که وظیفه توسعه بخش پایش رخدادها را به عهده دارد، نیست. جملات باید شفاف باشند. اگر روساخت بخش پایش، عملکرد سالمی نداشته باشد چه می‌شود؟ چه هزینه‌ای برای مشتریان و بهره‌برداران خواهد داشت؟ شرکت چه میزان پاسخگو خواهد بود؟ این سوالات باید پاسخ‌های شفافی داشته باشند.
یکی از مسائلی که در پروژه‌های زیرساختی وجود دارد حس درجا زدن و عدم حرکت در لبه‌ی توانمندی‌های مرتبط با اعضای تیم است. این در حالی است که به تجربه به من ثابت شده است که چالش‌های پروژه‌های زیرساختی بسیار زیاد و به مراتب پیچیده‌تر هستند. ممکن است جنسی از چالش‌ها در اینجا وجود نداشته باشد اما به دلایل مختلف در مسیر توسعه این پروژه‌ها، نه تنها چالش‌های منحصر به فردی بررسی و مرتفع می‌شوند بلکه چالش‌های مرتبط با محصولات کاربرمحور هم مرور می‌شوند.
نکته‌ی مهم دیگر در این مسیر، آموزش‌های متنوع به فراخور چالش‌های موجود در این محصولات است. مهم است که برای اعضای تیم مرور شود که چه چیزهایی در طول مسیر توسعه این محصول یاد گرفته‌اند و دانش آن‌ها چقدر در مسیر توسعه رشد کرده است. مقایسه این میزان از یادگیری با آنچه که در محصولات کاربر محور اتفاق می‌افتد نیز می‌تواند در بسیار از موارد ذهن افراد را نسبت به جذابیت کار شفاف‌تر کند.
در برخی موارد به دلیل محرمانگی‌های خودساخته و گاهی هم به دلیل پیچیدگی‌های ذاتی صورت مساله‌ی محصولات زیرساختی، مدیران و توسعه‌دهندگان ارشد از توصیف آنچه که در کاربرد محصول در حال وقوع است طفره می‌روند و به صورت قطره‌ای و در بازهی زمانی طولانی‌مدتی یک تصویر نسبتا شفاف از محصول به همکاران ارائه می‌دهند. بخشی از این اتفاق طبیعی است. اما این مهم است که فاصله ورود همکاران تا فهم مناسب آن‌ها از اهمیت و روش بهره‌برداری از محصولات، حداقل زمان ممکن باشد. هر چه زودتر توسعه‌دهندگان به ابعاد واقعی مساله و کاربرد محصول آشنا شوند، زودتر می‌توانند برای مسائل راه‌حل داشته باشند و احساس خوبی از کار در محصول را داشته باشند.
وجود مستندات و مصورسازی که قبل‌تر ذکر شد، می‌تواند در این گام نیز بسیار کمک‌کننده باشد. مستندسازی را همیشه جدی بگیرید.
محصولات زیرساختی به صورت ذاتی طیف گسترده‌ای از دانش را با خود به همراه می‌آورند. اما در عین حال حجم بالای فعالیت مورد نیاز برای توسعه این محصولات، منتج به شکل‌گیری ساختارهای سازمانی بزرگ و پیچیده‌ای می‌شود. خروجی این ساختارهای بزرگ و سنگین، تیم‌هایی با وظایف محدود و مشخص است که کمتر از آنچه در باقی تیم‌ها می‌گذرد اطلاع دارند. این امر نه تنها منتج به جزیره‌ای شدن سازمان خواهد شد، بلکه همان حس درجازدن را در کارکنان تقویت خواهد کرد.
می‌توان با تعریف روال‌های پایدار و منظمی از ارائه‌ها و دورهمی‌های مختلف فنی، دانش را بین اعضای شرکت به اشتراک گذاشت و همه‌ی تیم‌ها را با ابعاد کلان مساله آشنا کرد. تیم‌ها می‌توانند به صورت ماهانه آن بخش از محصول یا محصولاتی را که آماده‌ی انتشار کرده‌اند برای اعضای شرکت نمایش دهند و چالش‌های مختلف را با آن‌ها به اشتراک بگذارند.
ساختارهای پیچیده‌ای که البته به نظر من بخش ناگزیر محصولات زیرساختی هستند، در برخی موارد سدی در مقابل خلاقیت و بروز ایده‌های نو توسط توسعه‌دهندگان می‌شوند. دادن اختیارات مشخص با حفظ نظم توسعه سبد محصول، می‌تواند کمی از این مشکل را برطرف کند و اجازه دهد تیم‌ها خلاقیت‌های خود را در روال توسعه محصولات بروز دهند. ارائه الگوهای مناسب از این خلاقیت‌ها به سایر تیم‌ها می‌تواند انگیزه‌ی مضاعفی برای افراد خلاق باشد.
یکی از بزرگترین مشکلات در محصولات زیرساختی، کندی روند انتشار محصول است. به این ترتیب که با تعریف حداکثری نیازمندی‌ها از سمت مشتری، محصول در یک بازهی زمانی بلندمدت به انتشار می‌رسد و همین باعث فرسودگی و کاهش انگیزه‌ی اعضای تیم می‌شود.
بهتر است به جای اجرای یک طراحی بی‌نقص و شامل تمام نیازمندی‌های مشتری، محصول را به فازهای کوچکتر تقسیم کرده و در محدوده‌های زمانی کوتاه‌تری گام به گام به انتشار نهایی نزدیک کنید. خطاها در سطوح مختلف معماری، طراحی و پیاده‌سازی را در این مسیر را بپذیرید. باور کنید که هزینه‌ی این خطاها در بلند مدت و با ایجاد انگیزه در تیم جبران خواهد شد. انتشار پایلوت‌های مختلف روی شبکه مشتری می‌تواند انگیزه‌ی اصلی در این مسیر باشد. اجزای محصول را به مرور و جز به جز روی شبکه آزمایشگاهی و یا بخش کوچکی از شبکه مشتری منتشر کنید. این امر فرسایش تیمی را کمتر کرده و تیم را زودتر با چالش‌های مختلف مشتری روبرور می‌کند.
محصولات کاربرمحور در راستای ایجاد چهره‌ای جذاب و فنی به کاربران خود، به راحتی دانش کسب شده در محصول را به سایرین به اشتراک می‌گذارند و حتی از این امر برای بهبود وجهه‌ی فنی خود بهره می‌گیرند. اما محصولات زیرساختی به دلایل مختلف تجاری و یا محدودیت‌هایی از طرف کارفرمای پروژه کمتر دانش خود را به اشتراک می‌گذارند. همین امر سبب می‌شود که امکان ساخت یک چهره‌ی فنی از توسعه‌دهندگان سلب شود.
اما در بسیاری از موارد، محصولات زیرساختی نیز می‌توانند با حذف داده‌های شخصی از دانش موجود، سخت‌گیری کمتر در انتشار اطلاعات محصول و همچنین اختصاص زمان کاری برای انتشار دانش به صورت عمومی، اجازه دهند تا توسعه‌دهندگان تجارب خود را با سایرین به اشتراک بگذارند و وجهه فنی شخصی خود را بهبود دهند. امری که برای بخش بزرگی از توسعه‌دهندگان نرم‌افزار در فضای کاری امروز مهم و تاثیرگذار است.
واضح است که بخشی از تعریف مسیر پیشرفت برای افراد به تصمیمات کلان در سطح محصول و سازمان برمی‌گردد. اما نباید از این نکته هم غافل شد که می‌توان مستقل از تصمیمات کلان سازمانی، برای هر توسعه‌دهنده مسیر پیشرفت شغلی و شخصی نسبتا معقولی را تعریف کرد که در آن فرآیند یادگیری و بهبود توانایی‌های فنی و غیرفنی افراد هدف‌گذاری شود. این امر پیچیدگی چندانی ندارد و با شناخت کافی از شخصیت توسعه‌دهندگان و گاهی با گفتگو و تعامل قابل دستیابی است.
چالش اصلی در این بخش تعریف همان مسیر پیشرفت سازمانی است که در محصولات زیرساختی با ساختار عریض و طویل، کمی پیچیده است. با همکاری سازمانی می‌توان این موضوع را نیز شفاف کرد که البته حقیقتا این یکی، از سخت‌ترین کارها در محصولات زیرساختی است.
هدف من از انتشار این یادداشت یادآوری برخی نکات به خودم و همکارانم در پروژه‌های توسعه نرم‌افزارهای زیرساختی بود. سعی کردم مواردی که می‌گویم وابستگی زیادی به ساختار سازمان و تصمیمات کلان سازمانی نداشته باشد. به نظر من این مجموعه گام‌ها در سطح هر تیمی قابل اجرا است و از این نظر می‌تواند برای مدیران میانی سازمان‌ها بسیار کمک‌کننده باشند. البته که حتما می‌توان گام‌های بیشتری هم برداشت.
