قرار نبود مدیر محصول شوم. قرار بود نرمافزاری بسازم که کار کند؛ مایگریشن تمیز، API منطقی و صفهایی که ساعت دو نیمهشب از پا نیفتند. بعد از پنج سال و کلی لاراول، فهمیدم سختترین مسئلهها هیچوقت فنی نبودند. سختترینشان سؤالی بود که هیچ اندپوینتی جوابش را نمیداد: اصلاً باید این را بسازیم؟ و برای چه کسی؟
مهندسی به من یاد داد به محدودیتها احترام بگذارم
یک برنامهنویس بکاند درون محدودیتها زندگی میکند؛ شکل داده، هزینهی یک کوئری و دامنهی خرابی یک مایگریشن روی جدولی که زنده است. همین غریزه، قابلانتقالترین مهارتی بود که داشتم. حالا وقتی سر میز نقشهراه مینشینم، تفاوت میان قابلیتی که یک هفته کار دارد و قابلیتی که بیسروصدا نیمی از سیستم را بازنویسی میکند میشنوم. تخمینها دیگر حدس نیستند، گفتوگو هستند.
محصول به من یاد داد به کاربر بیشتر از معماری احترام بگذارم
مهندسی به ظرافت پاداش میدهد. محصول به نتیجه پاداش میدهد، و کاربر اهمیتی نمیدهد راهحل چقدر ظریف است اگر به روزش نخورد. ورود به مدیریت محصول مرا وادار کرد دو حقیقت را همزمان نگه دارم: سیستم باید سالم بماند و آدمِ آنسوی صفحه باید در سی ثانیهی اول موفق شود. در فناوری اطلاعات سپهر، جایی که پلتفرمهای فروشگاهی و بازاریابی میسازیم، تمامِ کار همین کشمکش است.
چیزی را که نمیفهمی نمیتوانی اولویتبندی کنی — و محصول را فقط از بیرون نمیشود فهمید.
چه میگفتم به خودِ گذشتهام
اگر مهندسی هستی که با خودت کلنجار میروی این تغییر ارزشش را دارد یا نه: عمق فنیات بار اضافه نیست، اهرم است. همین است که میگذارد یک تخمین اشتباه را به چالش بکشی، وابستگی پرریسک را ببینی و اعتماد کسانی را بگیری که قرار است واقعاً بسازندش. کدی که نوشتی انحراف از مسیر محصول نبود، کارآموزیاش بود.
این نخستین نوشته روی سایتی است که سرتاپا خودم ساختم؛ نکستجیاس در جلو، لاراول در پشت، دوزبانه از پایه. باز هم خواهم نوشت — دربارهی محصول، مهندسی و فضایی که این دو به هم میرسند.