چرا کندتر عرضهکردن گاهی عاقلانهتر است
نسخهای از «سریع حرکتکردن» هست که از بیرون پرثمر بهنظر میرسد و از درون، بیسروصدا فاجعهبار است. من در آن نسخه زندگی کردهام. کارفرماها را هم دیدهام که در آن زندگی میکنند. این چیزی است که یاد گرفتهام.
سرعت حس خوبی دارد؛ شتاب همان مخدر است
وقتی یک تیم سریع عرضه میکند، یک حس رضایت هست که تشخیصش از پیشرفت واقعی سخت است. جلسات روزانه پرانرژیاند. چنجلاگ طولانی است. مدیریت راضی است. برد Notion سراسر سبز است.
چیزی که دیده نمیشود: فهرست روبهرشدِ چیزهایی که کاملاً درست نبودند اما برای عرضهشدن بهاندازهی کافی خوب بودند. تستی که بهخاطر جابهجایی ددلاین حذف شد. بازبینی طراحیای که به یک ریاکشن در اسلک تبدیل شد. تصمیم معماریای که ساعت ۱۱ شب زیر فشار گرفته شد.
هرکدام از اینها یک بدهی کوچک است. تنها، هیچکدام جدی نیستند. اما با هم، پس از شش ماه انباشتهشدن، همان دلیلی میشوند که مهندس ارشدتان استعفا داده و چرخش نگهبانی (on-call) شما به یک کابوس تبدیل شده.
سه چیزی که سرعت هزینهشان میکند و هرگز روی نقشهراه دیده نمیشوند
۱. جهتیابی.
فهمیدن یک سیستم — واقعاً فهمیدنش — به توجه آرام نیاز دارد. وقتی همیشه در حال ساختناید، هرگز در حال یادگیری نیستید. بر اساس فرضهایی عرضه میکنید که شش ماه پیش منطقی بودند و از آن زمان زیر سؤال نرفتهاند.
۲. یکپارچگی طراحی.
رابطهایی که برای انسجام طراحی شده بودند، وقتی ده قابلیت توسط ده نفر در ده اسپرینت بدون یک بازبینی یکپارچهکننده اضافه میشوند، ناهمگون میشوند. کاربران متوجه میشوند. آن را «انحراف طراحی» نمینامند — میگویند محصول باگدار، ارزان یا گیجکننده بهنظر میرسد. و میروند.
۳. توانایی تغییر مسیر.
سرعت در جهت اشتباه، گرانترین نوع سرعت است. تیمهای سریع اغلب آخرین کسانیاند که میفهمند دارند بهجایی میروند که هیچکس نمیخواهد، چون آنقدر مشغول عرضهکردناند که سر بلند نمیکنند.
چه چیزی واقعاً از ریتم حسابشده بهدست میآید
استدلالم برای کندی بهعنوان یک هدف در خودش نیست. استدلالم برای سرمایهگذاری روی چیزهایی است که سرعت پایدار را ممکن میکنند:
- یک مدل ذهنی مشترک از اینکه سیستم چطور کار میکند و چرا.
- بازبینیهای طراحی که پیش از کد اتفاق میافتند، نه بعد از آن.
- پوشش تست خودکار روی مسیرهایی که واقعاً اهمیت دارند.
- فرهنگ پسمرگنگاری (post-mortem) که در آن «خیلی سریع عرضه کردیم» بتواند پاسخ صادقانه باشد.
اینها لوکسبازی برای تیمهایی نیستند که به آنها رسیدهاند. اینها پایهایاند برای تیمهایی که میخواهند سریع حرکت کنند بدون اینکه خودشان را نابود کنند.
این در عمل چه شکلی است
یک کارفرمای مارکتپلیس با خواست یک بازطراحی بصری سریع، پس از نرخ رهاشدن سبد خرید موبایل ۶۸٪، سراغم آمد. نسخهی سریعِ این پروژه، صفحهی پرداخت را بازطراحی میکرد و در کمتر از یک هفته عرضه میکرد. در عوض، دو هفتهی اول فقط صرف مشاهده شد: تستهای کاربردپذیری هدایتشده با ۱۲ شرکتکننده، بهعلاوه تحلیل ضبط جلسات روی ۴۰,۰۰۰ بازدید واقعی. همان شروع کندتر بود که نقاط شکست واقعی را آشکار کرد — یک پرداخت هفتمرحلهای بدون گزینهی مهمان، تصاویر محصول ناهمگون که اعتماد را میفرسود، و LCP صفحهی اصلی ۸٫۴ ثانیه روی ۴G. هیچکدام از اینها اگر مستقیم به بازطراحی بر اساس فرض میرفتید، دیده نمیشد. همان دو هفتهی «بیثمر بهنظر رسیده» تحقیق، همان چیزی بود که هفتههای بعدیِ ساختن را مؤثر کرد، نه فقط سریع.
پرسشی که از کارفرماها میپرسم
وقتی کسی میگوید تیمش باید سریعتر شود، یک پرسش میپرسم: سریعتر از چه؟
سریعتر از رقیب؟ احتمالاً نه — رقیب همان بدهی شما را دارد.
سریعتر از آنچه کاربرانتان میتوانند جذب کنند؟ قطعاً نه — پذیرش کندتر از عرضه است.
سریعتر از آنچه میتوانید یاد بگیرید؟ آن یکی است که شرکتها را میکشد.
هدف عرضهی کمتر نیست. هدف عرضهی چیزهایی است که ماندگارند، و باقیگذاشتن ظرفیت کافی برای اصلاح چیزهایی که نمیمانند.
پرسشهای پرتکرار
آیا کندشدن یعنی ازدستدادن ددلاین؟ نه اگر سرمایهگذاری در چیزهایی برود که سرعت بعدی را ممکن میکنند — درک مشترک از سیستم، و تست روی مسیرهایی که اهمیت دارند. ددلاینی که با یک پایهی پایدار به آن میرسید، از ددلاینی که با قرضگرفتن از فصل بعد به آن میرسید، ارزش بیشتری دارد.
چطور فرق بین احتیاط سالم و معطلی را بفهمم؟ احتیاط سالم یک خروجی تولید میکند — یک بازبینی طراحی، یک اسپایک، مجموعهای از سناریوهای تست. معطلی هیچ خروجیای تولید نمیکند، فقط تأخیر. اگر بخش کند چیزی ملموس تولید نمیکند که بتوانید نشانش دهید، همان ریتم حسابشدهای که این مقاله از آن دفاع میکند نیست.
این دقیقاً همان چیزی است که در خدمات مشاورهی فنی من به کار میرود. سؤالی دربارهی ریتم پروژهی خودتان دارید؟ تماس بگیرید.
این مطلب برایتان مفید بود؟
شمارش آرا پس از ۵ رأی نمایش داده میشود.
مقالات مرتبط
چرا طراحی خوب یک مهارت فنی است
بهترین طراحانی که میشناسم مثل مهندس فکر میکنند. و بهترین مهندسان مثل طراح فکر میکنند. اینجا دلیلش را میگویم که چرا آن همپوشانی جادویی است.
مطالعه مقالهساختن قابلیتهای هوش مصنوعی که کاربران واقعاً میخواهند
همه میخواهند به محصولشان هوش مصنوعی اضافه کنند. بیشتر تیمها این کار را اشتباه انجام میدهند. چارچوبی برای تشخیص جایی که هوش مصنوعی واقعاً ارزش میآفریند از جایی که فقط هیاهوست.
مطالعه مقالهامبیای چه چیزی را در نحوهی ساختن نرمافزار تغییر داد
مهندسی به من یاد داد درست بسازم. مدرسهی کسبوکار یاد داد چیزِ درست را بسازم — و تفاوت این دو را بفهمم.
مطالعه مقاله