۱۴۰۵/۰۵/۲۷

چرا هنوز از ساختن فاصله نمی‌گیرم

۴ دقیقه مطالعه

هرچه مسئولیت‌های کاری‌ام بیشتر شده، زمان کمتری برای ساختن مستقیم چیزها داشته‌ام.

طبیعی هم هست.

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

اما چیزی که مدتی است بیشتر به آن فکر می‌کنم، خودِ کم شدن زمان نیست.

فاصله است.

فاصله‌ای که ممکن است آرام‌آرام بین کسی که درباره‌ی یک محصول تصمیم می‌گیرد و آدم‌هایی که واقعاً آن را می‌سازند شکل بگیرد.

مسئله فقط Coding نیست

فکر نمی‌کنم یک CTO یا مدیر محصول الزاماً باید هر روز Code بزند.

حتی فکر نمی‌کنم بهترین مدیر فنی لزوماً بهترین برنامه‌نویس تیم باشد.

مسئله برای من چیز دیگری است.

اگر قرار است درباره‌ی زمان ساخت یک Feature تصمیم بگیرم، باید تا حد قابل قبولی بفهمم ساختنش واقعاً چه معنایی دارد.

اگر قرار است درباره‌ی Architecture حرف بزنم، نباید تصویرم از زیرساخت فقط چند Box روی یک Diagram باشد.

اگر درباره‌ی سرعت تیم Engineering تصمیم می‌گیرم، باید بدانم بخشی از زمانی که از بیرون «کندی» به نظر می‌رسد ممکن است صرف چیزهایی شود که هیچ‌وقت در Demo دیده نمی‌شوند.

Migration.

Monitoring.

Logging.

Refactor.

Failover.

Security.

و گاهی فقط پیدا کردن یک Bug مسخره که چند ساعت زمان می‌برد.

هرچه فاصله از این واقعیت بیشتر شود، تصمیم گرفتن راحت‌تر می‌شود.

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

روی کاغذ همه‌چیز ساده‌تر است

در یک جلسه خیلی راحت می‌شود گفت:

«این Feature که چیز خاصی نیست.»

«این API را وصل کنیم.»

«تا آخر هفته Deliver می‌شود.»

«اگر این Provider مشکل داشت، برویم روی یکی دیگر.»

خیلی از این جمله‌ها از نظر Product کاملاً منطقی‌اند.

اما فاصله‌ی بین یک تصمیم منطقی و Implementation واقعی گاهی خیلی بیشتر از چیزی است که روی کاغذ دیده می‌شود.

کار روی محصولات AI این موضوع را برای من پررنگ‌تر کرد.

وصل کردن یک API معمولاً قسمت ساده و حتی جذاب ماجراست.

سختی از جایی شروع می‌شود که Provider از دسترس خارج می‌شود، Usage باید دقیق محاسبه شود، هزینه باید کنترل شود، Logها باید قابل پیگیری باشند و کاربر وقتی همه‌چیز طبق برنامه جلو نرفت همچنان باید یک تجربه‌ی قابل‌فهم داشته باشد.

چیزهایی که اگر مدت زیادی از ساختن فاصله بگیری، خیلی راحت تبدیل می‌شوند به چند کلمه داخل یک Task.

برای همین هنوز دستم را کثیف می‌کنم

هنوز پیش می‌آید یک شب درگیر Docker شوم.

Nginx را Debug کنم.

روی یک Server چیزی Deploy کنم.

دنبال مشکل SSL بگردم.

یا روی یک پروژه‌ی کوچک Code بزنم فقط برای اینکه بفهمم چیزی که درباره‌اش تصمیم می‌گیریم در عمل چطور کار می‌کند.

بعضی وقت‌ها نتیجه‌اش فقط این است که چند ساعت بعد بفهمم راهی که در ذهنم ساده بود، اصلاً ساده نبوده.

و همین برایم ارزش دارد.

نه چون می‌خواهم ثابت کنم هنوز Technical هستم.

بیشتر چون نمی‌خواهم تصمیم‌هایی بگیرم که فقط از دور منطقی به نظر می‌رسند.

اما نزدیک بودن با دخالت کردن فرق دارد

این طرف ماجرا هم خطر خودش را دارد.

نزدیک ماندن به ساختن به این معنی نیست که مدیر فنی باید هر Pull Request را خودش بررسی کند، هر تصمیم را خودش بگیرد یا هر مشکلی را از دست تیم بگیرد.

اگر تیم برای هر تصمیم منتظر یک نفر بماند، خیلی زود همان آدم تبدیل به Bottleneck می‌شود.

آن دیگر Technical Leadership نیست.

احتمالاً Micromanagement است.

برای من چالش دقیقاً همین‌جاست:

آن‌قدر نزدیک بمانم که واقعیت ساختن را بفهمم، اما آن‌قدر وارد نشوم که تیم نتواند بدون من حرکت کند.

و فکر نمی‌کنم برای این تعادل یک فرمول ثابت وجود داشته باشد.

گاهی باید وارد جزئیات شوی.

گاهی دقیقاً بهترین کاری که می‌توانی انجام بدهی این است که کنار بروی و اجازه بدهی تیم خودش مسئله را حل کند.

هنوز هم دارم این قسمت را یاد می‌گیرم.

خیلی از چیزهایی که درباره Product یاد گرفتم، از Product نیامدند

بعضی چیزها را از Support یاد گرفتم.

بعضی را از Debug کردن.

بعضی را از Featureهایی که روی کاغذ ساده بودند و در عمل نبودند.

و بعضی را از چیزهایی که ماه‌ها ساختیم و بعد فهمیدیم کاربر اصلاً آن‌طور که تصور می‌کردیم از آن‌ها استفاده نمی‌کند.

فکر می‌کنم ساختن یکی از سریع‌ترین راه‌ها برای برخورد کردن با واقعیت است.

تا وقتی چیزی فقط در ذهن است، تقریباً همه‌ی فرضیه‌ها می‌توانند درست باشند.

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

شاید همیشه خودم نسازم

ممکن است چند سال دیگر نقش من باز هم تغییر کند.

ممکن است زمان خیلی کمتری برای Coding داشته باشم.

ممکن است دیگر خودم هیچ Serverی را Deploy نکنم.

این بخش برایم مسئله نیست.

چیزی که دوست ندارم از دست بدهم، ارتباط با نحوه‌ی واقعی ساخته شدن محصول است.

لازم نیست همیشه خودم سازنده‌ی مستقیم همه‌چیز باشم.

اما اگر قرار است درباره‌ی ساختن تصمیم بگیرم، می‌خواهم آن‌قدر نزدیک بمانم که سختی‌هایش را فراموش نکنم.

شاید برای همین است که هنوز بعضی شب‌ها Terminal را باز می‌کنم.

نه برای اینکه به گذشته برگردم.

برای اینکه فاصله‌ام با چیزی که درباره‌اش تصمیم می‌گیرم، زیادی زیاد نشود.