علی خباز
خواندن ۵ دقیقه·۹ روز پیش

تله استارتاپ

[ترجمه ای به کمک هوش مصنوعی از مطلبی با همین عنوان از رابرت سی مارتین]

  • تو به یک استارتاپ جدید پیوسته‌ای
  • تو یک موجود فوق‌العاده با استعدادهای متعدد هستی
  • می‌توانی ۶۰، ۷۰، ۸۰ ساعت در هفته کار کنی تا کار را به سرانجام برسانی
  • تو یک برنامه‌نویس و طراح درجه‌یک هستی
  • تو در دام‌هایی که دیگران گرفتارشان شده‌اند، نخواهی افتاد
  • تو مطمئن می‌شوی که این بار اوضاع فرق دارد
  • تو آن‌قدر خوب هستی که قوانین برایت معنایی ندارند
  • ... تو به فنا رفته‌ای

تله استارتاپ

این داستان غم‌انگیزی است که بارها و بارها شاهدش بوده‌ایم. یک برنامه‌نویس جوان، با نیت‌های عالی شروع می‌کند، تمام اصول درست را یاد می‌گیرد، تمام مهارت‌های لازم را به دست می‌آورد، و سپس در دام تله استارتاپ می‌افتد.

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

تله استارتاپ این فکر است که فاز اولیه استارتاپ فرق دارد؛ و اینکه در این مرحله، موفقیت وابسته به زیر پا گذاشتن قوانین است. این طرز فکر کاملاً احمقانه است. فاز اولیه استارتاپ، صرفاً اولین مرحله از مراحل متعدد رشد شرکت است و همان‌طور که این فاز را پیش می‌بری، فرهنگ سازمان را برای آینده شکل می‌دهی. اگر پنج سال دیگر به همان شرکت برگردی (اگر زنده مانده باشد)، می‌بینی که همان رویکردی که در مرحله اولیه داشتند، هنوز هم پابرجاست – البته شاید به جز اضافه‌کاری‌های بی‌پایان! (خنده)

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

یکی از این اصول، توسعه مبتنی بر تست (TDD) است. هرکسی که فکر می‌کند بدون نوشتن تست می‌تواند سریع‌تر حرکت کند، سخت در اشتباه است. بله، می‌دانم که تو یک جنگجوی شکست‌ناپذیر هستی. می‌دانم که همیشه کد را بدون نقص می‌نویسی. می‌دانم که ضرب‌الاجل نزدیک است و وقت نداری که تست بنویسی. اما متأسفم برای شکست‌های پیش رویت. متأسفم که داری کُند حرکت می‌کنی و هنوز متوجه نشده‌ای. و بیشتر از آن، متأسفم که وقتی بالاخره با زحمت و تقلای زیاد به یک موفقیت نسبی دست پیدا کردی، این رفتار بدت را به‌عنوان یک روش درست تبلیغ خواهی کرد و به دیگران پیشنهاد می‌دهی. خدا به همه ما رحم کند، چون تو نخواهی کرد!

از خودت بپرس: حسابدار یک استارتاپ چگونه رفتار می‌کند؟ این فرد مسئول مدیریت پول سرمایه‌گذاران است. فکر می‌کنی او هم ضرب‌الاجل دارد؟ فکر می‌کنی تحت فشار است تا گزارش‌های مالی، پیش‌بینی‌ها و جریان نقدینگی را ارائه دهد؟ فکر می‌کنی مدیران شرکت، تأخیرهای او را تحمل می‌کنند؟

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

حالا به رفتار او دقت کن: آیا کارهایش را دوباره بررسی می‌کند؟ آیا حسابداری دوطرفه انجام می‌دهد؟ آیا تمام قوانین و اصول را رعایت می‌کند؟ یا چون در فاز استارتاپ هستند، قوانین را زیر پا می‌گذارد؟

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

تو بلافاصله اخراجش می‌کردی! آن‌قدر سریع که خودش هم نمی‌فهمید چطور از شرکت بیرون انداخته شده است!

آیا کد تو از صورت‌حساب‌های مالی کم‌اهمیت‌تر است؟ آیا خطاهای کد، قابل‌تحمل‌تر از خطاهای مالی هستند؟ آیا یک باگ در کد نمی‌تواند اعتبار شرکت را خدشه‌دار کند، مشتریان را از بین ببرد، و سرمایه‌گذاران را فراری دهد؟ خودت جواب این سؤال‌ها را می‌دانی. و این را هم می‌دانی: اگر حسابداران می‌توانند در یک استارتاپ، اصول خود را رعایت کنند، تو هم می‌توانی!

آیا کنار گذاشتن TDD باعث می‌شود سریع‌تر پیش بروی؟ بگذار جوابی بدهم در حد واکنش کاپیتان سولو وقتی که انفجار ماه قدرتی کلینگون رخ داد و یک افسر جوان پرسید که آیا باید ماجرا را به استارفلیت گزارش کنند؟

"شوخی می‌کنی؟" واقعاً شوخی می‌کنی؟

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

  • چون دیگر نمی‌توانی کد را بازآرایی (Refactor) کنی.
  • کد به‌سرعت فرسوده و غیرقابل نگهداری می‌شود.
  • تغییرات جدید سخت‌تر و سخت‌تر می‌شوند.
  • باگ‌ها بیشتر و بیشتر می‌شوند.
  • تو مجبور می‌شوی بین باگ‌های «بحرانی» و «قابل‌قبول» تمایز قائل شوی (انگار که هیچ باگی قابل‌قبول است!).
  • ماژول‌هایی خواهی ساخت که آن‌قدر شکننده‌اند که جرئت نمی‌کنی آن‌ها را تغییر دهی، پس آن‌ها را دور می‌زنی.
  • و به‌جای پیشرفت، یک توده گندیده از کد خواهی ساخت که هر هفته، انرژی بیشتری برای نگهداری آن نیاز است.

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

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

اگر می‌خواهی سریع باشی، اگر می‌خواهی ضرب‌الاجل‌هایت را رعایت کنی، اگر می‌خواهی موفق شوی، پس توصیه‌ای بهتر از این ندارم:

به اصولت پایبند باش! تست بنویس. کدت را مرتب و تمیز نگه دار. عجله نکن!

تو مسئول خونِ زندگی‌بخش استارتاپت هستی. با آن سهل‌انگارانه رفتار نکن!

یادت باشد: تنها راه سریع رفتن، این است که درست بروی.


منبع

شاید از این پست‌ها خوشتان بیاید