بازار نرم‌افزار سیال و پر رفتامد است درست مثل خود نرم‌افزار! جابجایی نیروها در بین تیم‌ها و شرکت‌ها پربسامد است. امروز وارد یک تیم می‌شوید. ماه بعد تیم شما با تیم دیگری ادغام می‌شود. ماه بعدی عضو کلیدی از تیم جدا می‌شود. پررنگ‌ترین حالت این چالش، جدایی اعضای ارشد (Senior) سازمان است که در روزها و سال‌های اخیر خصوصا در بازار نرم‌افزار ایران بسیار رایج است؛ به امید روزهای بهتر برای این آب و خاک.
در این نوشته می‌خواهم به یکی از مهم‌ترین مهارت‌هایی که یک مهندس نرم‌افزار به آن احتیاج حیاتی دارد اشاره کنم: مهارت تحویل گرفتن یک سرویس (Artifact).
من با مسامحه از لغت آشنای سرویس بجای آرتیفکت (Artifact) استفاده کردم. منظورم هر محصول نرم‌افزاری است که در یک تیم فنی طراحی، نگهداری و توسعه داده می‌شود. راستش استفاده از معادل‌های فارسی‌اش برایم آسان نبود: دست‌ساز، مصنوع، پردازش‌ماند. بعضی از دوستان از کلمه‌ی بانمک «جنس» به عنوان معادل آرتیفکت استفاده می‌کنند!
آرتیفکت شامل هر چیزی است که برای توسعه‌ی محصول تولید شده است: کد، داکیومنت‌ها، اسکریپت‌ها، سرورهای پروداکشن و ساختار استقرار فعلی (Deployment Setup) و البته مقدار زیادی دانش که به شکل نامرئی در بین اعضای تیم وجود دارد.
درک دقیق شرایط تیم، سازمان و جایگاه سرویس مورد نظر در این بافت، راهگشاست. از همه مهم‌تر درک شرایط صاحب (owner) قبلی سرویس است. باید درک کنیم که احتمالا در آستانه‌ی جدایی این همکار ما، دغدغه‌های بسیار متفاوتی نسبت به روزهای معمول حضورش در تیم دارد. مثلا در حال مصاحبه برای شغل جدید است، در حال مهیا شدن برای مهاجرت است، بعد از یک دوره پرفشار نیاز به استراحت دارد و در کل: ریتم عملکرد معمولش را ندارد. درک این واقعیت خیلی می‌تواند شما را در نتظیم رفتارهایتان یاری کند.
به قول شاعر خداحافظ همین حالا، همین حالا که من تنهام!
همین امروز سرویس را تحویل بگیرید حتی اگر تحویل‌دهنده‌ی عزیز قرار است یک ماه همراه تیم باشد. غفلت در این کار بسیار پرهزینه خواهد بود. اتفاقی که می‌افتد: درخواست‌های پشتیبانی و اضطراری (Emergency) یکی در پی دیگری سر می‌رسد؛ تحویل‌دهنده عملکرد پربازده (Productive) سابقش را ندارد. مثلا اگر قبلا ده واحد در روز کار تحویل می‌داد، حالا با توجه به شرایط شخصی و دغدغه‌هایش هفت واحد انرژی کاری دارد. در نتیجه بیشتر این انرژی، صرف این پشتیبانی‌ها شده و اصلا چیزی برای آنبوردینگ شما و تحویل سرویس نمی‌ماند. از همان روز اول فعالانه در جبهه‌ی اول نگهداری سرویس قرار بگیرید. هر درخواست، تیکت و فیچری باید توسط شما پیاده‌سازی شود. با این کار البته یکباره استرس زیادی به شما وارد می‌شود؛ ناگهان ریتم توسعه‌ی آن سرویس افت خواهد کرد و حتی ممکن است از همکارانتان فیدبک منفی دریافت کنید، اما این کار لازم است تا بیشترین دیتای ممکن به شما منتقل شود و هر چیزی را که نمی‌دانستید، خودتان از تحویل‌دهنده‌ی عزیز بپرسید. هر قدر ارتباط موثرتری با تحویل‌دهنده داشته باشید، هزینه‌های این دوره کاهش می‌یابد.
باورم کنید؛ برگزاری یک سلسله جلسات تحویل سرویس اصلا کافی نیست بلکه پس از یکی دو جلسه، ممکن است به کل بی‌فایده باشد. بهترین ترکیب به تجربه‌ی من این است؛ جلساتی برای آشنایی اولیه و کلی با معماری سرویس، هر قدر مختصرتر بهتر؛ با پرداختن به ستاپ فعلی آن. سپس بلافاصله قرار گرفتن در جبهه اول پیشبرد سرویس و در کنار آن ادامه‌ی جلسات به درخواست و اعلام نیاز شما و نه لزوما طبق یک برنامه مشخص.
شاهد ادعایم آن جاست که در نوع اول جلسات تحویل‌گیرنده نهایتا دچار توهم مسلط شدن روی همه‌ی جزئیات سرویس می‌شود، تحویل‌دهنده هم احساس می‌کند همه چیز را گفته و خدا را شکر می‌کند که این بار گران به زمین نهاده است. قول می‌دهم فردای روز خداحافظی تحویل‌دهنده فاجعه رخ خواهد داد. اما در نوع دوم به خوبی نکات مبهم برایتان روشن می‌شود و هر جلسه را با یک خروار سوال و مشورت موثر و کلیدی پیش خواهید برد.
در این شرایط به دنبال کامل‌ترین یا زیباترین روش مستندسازی نباشید. به «راحت‌ترین» روش فکر کنید. مثلا اگر قرار است دپلویمنت سرویسی را مستندسازی کنید که تماما اتومیت نیست، به راحتی با یک Screen Recorder کل فرایند را ضبط کنید. نه زحمتی برای شما ایجاد می‌کند نه برای تحویل‌دهنده. انتظار نداشته باشید با شرایطی که عرض کردم تحویل‌دهنده بنشیند و مستند کامل و جامعی برای شما بنویسد. از سویی اگر شما نیز به این کار بپردازید شاید درگیر جزئیات حاشیه‌ای شده و از متن اصلی باز بمانید. در تیم‌های چابک (Agile) معمولا ارتباط (Communication) را به مستندسازی‌های رسمی (Documentation) ترجیح می‌دهند، در نتیجه چندان نمی‌توان روی مستنداتی که تا این لحظه آماده شده است مطمئن بود و خوب است در بازه‌ی تحویل به فکر تکمیل مستندات باشید. اگر بتوانید بیشتر صدا و تصویر ضبط کنید و بعدا سر فرصت به تدوین و مکتوب کردن آن‌ها بپردازید سریع‌تر و روان‌تر پیش می‌روید.
به خاطر بسپارید؛ الان وقت انتقاد از تصمیمات فنی و سازمانی تحویل‌دهنده نیست. به این مثال توجه کنید.
«ای بابا... نباید از پایتون استفاده می‌کردی، بدیهیه این زبان استاتیک تایپینگ نداره و با بزرگ شدن کد بیس هزینه‌ی نگهداری رو در دراز مدت بالا می‌بره.»
این جمله می‌تواند فاتحه‌ی کل داستان تحویل سرویس را بخواند. شاید با خود می‌گویید که اگر تحویل‌دهنده حرفهای باشد، این را یک فیدبک فنی خواهد دید. بله قطعا! اگر تحویل‌دهنده حرفهای و اخلاقمند نباشد که از ابتدا فاتحه‌ی پروژه‌ی تحویل خوانده است. مساله اصلا برخورد شخصی نیست بلکه فضایی است که این نوع نگاه می‌سازد. این نوع نگاه به مساله ناخودآگاه فضای دفاعی ایجاد می‌کند که بسیار مضر است و جلوی انتقال خالص اطلاعات را می‌گیرد و همه‌ی این اتفاقات کاملا ناخودآگاه و مستقل از اخلاق حرفهای دو طرف ممکن است رخ دهد. الان وقت «ارزیابی گذشته» نیست، الان وقت «آینده‌نگری» است؛ به جای آن می‌توان گفت:
«بسیار خوب، علت استفاده از پایتون در شروع توسعه‌ی محصول احتمالا سرعت پیاده‌سازی و رسوندن فیچر‌های ارزشمند بوده، درسته؟ لطف می‌کنی یکم بیشتر درباره‌ی فضای اتخاذ این تصمیم در آن زمان برام بگی. با توجه به مسیر طی شده، به نظرت خوبه در آینده با استفاده از ابزارهایی مثل mypy برای تایپ-سیف کردن کد-بیس برنامه‌ریزی کنیم تا هزینه‌ی نگهداری کاهش پیدا کنه؟»
نوع دوم نگاه فضای ذهنی‌ای در گفتگو حاکم می‌کند که به هیچ وجه به سمت دفاعی شدن نمی‌رود بلکه اتفاقا ذهن تحویل‌دهنده ناخودآگاه سعی می‌کند درس‌هایی را که در مسیر توسعه‌ی محصول گرفته است یادآوری کند. صمیمانه چالش‌ها را بیان خواهد کرد و احیانا راهکارهای آن را نیز مطرح می‌کند. نباید فراموش کرد که هر تصمیمی در زمان خودش ممکن است کاملا بجا و درست بوده باشد و نباید با اطلاعات امروز، درباره‌ی تصمیم‌گیرندگان دیروز بدون در نظر گرفتن شرایطشان قضاوت نمود.
همه‌ی ماجرا فنی و تکنولوژی نیست. حتما جویای «تاریخچه‌ی سرویس» شوید. به لحاظ تیمی و سازمانی، بپرسید داستان این سرویس چه بوده؟ چه آدم‌هایی با چه سلیقه‌هایی چه گام‌هایی برای آن برداشته‌اند؟ سخت‌ترین پیچ‌های مسیری که تا امروز طی شده چه بوده؟ تایخچه‌ی سرویس چه به لحاظ تصمیمات معماری فنی و چه به لحاظ تصمیمات سازمانی و بین‌تیمی، به طرز حیاتی شما را در تنظیم روابطتان با تیم‌های همکار یاری خواهد کرد. مثلا فرض کنید سرویسی دارید که پس از مدت‌ها بحث و بررسی فنی، تصمیم این شده که در آن از یک ابزار ارکستریتور مثلا داکر سوارم (Docker Swarm) استفاده شود؛ اما به دلیلی شما کوبرنتیز (Kubernetes) را مناسب‌تر می‌دانید اما این مهاجرت چندان حیاتی نیست. اطلاع شما از این تاریخچه؛ این راهنمایی را به شما می‌کند که صرفه‌جویی در ظرفیت روانی تیم و نپرداختن به این موضوع در آینده‌ی میان‌مدت و بجای آن تمرکز روی بهبودهای دیگری که چنین تاریخچه‌ای ندارند، بسیار ثمربخش‌تر از اصل این تغییر خواهد بود.
هم گفتگو با تحویل‌دهنده‌ی گرامی و هم در فضای تیم و سازمان؛ راجع به مدیریت دانش و اهمیت آن در یک تیم توسعه‌ی نرم‌افزار آگاهی ایجاد کنید. متاسفانه به رغم اهمیت حیاتی این موضوع، در ادبیات فنی و دانشگاهی معمول، کمتر به آن توجه شده است. یک نقطه‌ی شروع خوب می‌تواند گفتگو راجع به مفهوم دانش درونی‌شده (Knowledge Crunching) باشد که اریک اونس در کتاب معروف توسعه‌ی دامنه‌محور (Domain Driven Design) به آن می‌پردازد: تیمی می‌تواند با ریتم خوب به توسعه‌ی دامنه‌ی مساله بپردازد که به ادبیات صحیح و مشترک و غنی از مدل و دامنه‌ی مساله رسیده باشد. اما پرداختن به اهمیت این موضوع چه مزیتی هنگام تحویل گرفتن یک سرویس ایجاد می‌کند؟ با این کار از سویی این انگیزه را در تحویل‌دهنده تقویت می‌کنید که به عنوان یک مهندس نرم‌افزار از فرصت پیش‌آمده برای ایفای این نقش و پرورش این مهارت در خودش استفاده کند و از طرفی در اعضای دیگر تیم و سازمان نیز این نگاه و آمادگی را ایجاد می‌کنید که فعالانه در دریافت و ثبت دانش مربوط به سرویس بالخصوص دانش دامنه‌ی آن مشارکت کنند.
خوشبختی من این بوده که همکاران حرفهای داشته‌ام و همیشه در کارهای مختلف از آن‌ها درس آموخته‌ام. به هر روی این نوشته درس‌هایی است که از همه‌ی عزیزانی که روزی سرویسی را از آن‌ها تحویل گرفته‌ام، نوشتم. البته این حرف‌ها گزاره‌های علمی نیست بلکه حاصل تجربه و نگاه شخصی من است که بنا به اصل آزادی بیان آن را نوشتم. اگر با هر نکته‌ای در آن مخالفید؛ محبت می‌کنید نگاه متفاوت خود را بیان بفرمایید بلکه با گفتگوی حاصل، مخاطب به نگاه درست‌تری برسد. نوشته را با این یک شعر زیبا به پایان می‌برم چرا که احتمالا حین خداحافظی با یک همکار باتجربه، از حرفهای من بیشتر به کارتان بیاید!
خداحافظ به شرطی که بفهمی تر شده چشمام
خداحافظ کمی غمگین به یاد اون همه تردید
به یاد آسمونی که منو از چشم تو می دید
- از آهنگ خداحافظ همین حالا محمد علیزاده، شعر از فرزاد حسنی
