راهنمای مهندس کارکنان برای اختراع کار

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

خوشبختانه، سیگنال‌هایی که به ما در اختراع کار کمک می‌کنند، در حال حاضر وجود دارند، و از چهار جهت می‌رسند - از سیستم‌ها، از کاربران، از سازمان شما و از صنعت. آنچه در زیر می آید راهنمای خواندن هر یک از آنهاست.

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

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

هزینه، بر حسب دلار، یک امر بدیهی است. صورت حساب ابری کمبود درآمد شما را جبران می کند. اما در اینجا متوقف نشوید؛ فراتر از بهینه سازی پرس و جو پایگاه داده یا بررسی چگونگی کاهش هزینه های ترافیک بین VPC بروید. P/L واحد کسب‌وکارتان را در صورت موجود بودن بررسی کنید، یا قراردادهای فروشنده تیم‌تان و موارد صورت‌حساب ابری را بررسی کنید، یا از شخصی که به مراکز هزینه دسترسی یا آگاهی دارد، بپرسید. برای هر مرکز هزینه، درک کنید که "برون سپاری" آن عملکرد برای تیم شما چه سودی دارد، و چه معنایی دارد که آن را به محدوده تیم خود بکشانید.

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

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

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

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

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

بررسی تورنسل برای جذب ساده است: چه کسی در بین کاربران شما همین مشکل را دارد؟

موارد استفاده بیش از حد پس از این واقعیت کشف می شوند. شریک به نمونه اولیه همان چیزی است که به عمد ترتیب داده شده است: تیم شما و کاربران با هم کار می کنند تا چیزی را در پلتفرم شما نمونه سازی کنند که می تواند مشکل آنها را حل کند. نمونه اولیه وعده ای نیست که این ویژگی بخشی از پلتفرم خواهد بود. این به سادگی یک اکتشاف مشترک است. بررسی تورنسل برای یکسان سازی مانند موارد استفاده بیش از حد بارگذاری شده باقی می ماند: چه کسی در بین کاربران شما همین مشکل را دارد؟

این یکی دیگر از موارد آشکار است. من آن را برای کامل بودن فهرست می کنم. البته، اگر تیم شما یک OKR تنظیم کرده است (یا آن را تحویل داده است)، شما قبلا این مورد را اختراع کرده اید. تبریک می گویم! به سمت بعدی!

این یکی ساده و گاهی موثر است: اگر می شنوید که مدیر خود (یا مدیر او یا بالاتر) دو بار در هفته در مورد چیزی صحبت می کند، احتمالا یک نگرانی بدون توجه در پشت آن وجود دارد. این دلیل خوبی برای یادداشت برداری در 1:1 یا خواندن آنهایی است که توسط LLM ایجاد شده است. این اکتشافی، به نظر من، ضعیف‌ترین راه در میان بسیاری از روش‌های ابداع کار است. دلیل: هر چه سلسله مراتب بالاتر باشد، از کاربران دورتر است، و احتمال بیشتری برای ایجاد HiPPO (نظر پردرآمدترین افراد) وجود دارد.

هر تغییر عمده در پلتفرم نیاز به مهاجرت دارد، و هر کسی که یک مهاجرت حیاتی را رهبری کرده باشد می‌داند که پذیرش دارای دمی چاق است - به نظر می‌رسد منحنی معروف از Crossing the Chasm. شما مبتکران خود، پذیرندگان اولیه، اکثریت اولیه و دیررس خود و در نهایت عقب مانده های خود را خواهید داشت. تیم‌های عقب افتاده‌ای که پای خود را می‌کشند یا آن‌هایی که هرگز وارد آخرین پیشنهاد نمی‌شوند، سیگنال مهمی هستند: آنها به شما می‌گویند که چرا پیشنهاد شما ناقص است و چرا باید کارهای بیشتری انجام شود.

من قبلا استدلال کرده‌ام که پلتفرم‌های داخلی باید به مخاطبان وسیع‌تری نسبت به کاربر متوسط ​​پاسخ دهند. بقایای مهاجرت ما را به کاربرانی نشان می دهد که راه حل "متوسط" شما به آنها پاسخ نمی دهد.

ایده پردازی سخت است، اما وظیفه شما این است که ایده های جدیدی در مورد چگونگی بهبود یک سیستم موجود ارائه دهید (و این پیشرفت ها را به شکل تجویزی، مثلا RFC) پیشنهاد دهید. روش مورد علاقه شخصی من برای ارائه ایده، توصیف سیستم های موجود است (برای همتایان شما، برای کاربران، برای استخدام های جدید؛ شما مخاطبان خود را انتخاب می کنید). یک سند طراحی برای سیستمی که از قبل وجود دارد بنویسید و آن را با سیستم های پیشرفته ای که کار مشابه یا مجاور انجام می دهند مقایسه کنید. این عمل توصیف تصمیماتی را نشان می دهد که دیگر معنی ندارند. این در بهترین حالت نوشتن به عنوان تفکر است.

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

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

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

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

در انتهای دیگر سیگنال های نشستن شما باید برای آنها آرگومان بسازید. آربیتراژ تاخیر قوی ترین استدلال و ضعیف ترین جایگاه را به شما می دهد، زیرا شواهد از خارج از شرکت شما می آیند. اکتشافی تکرار مدیر هیچ شواهدی را به شما ارائه نمی دهد، اما با برخی موقعیت ها همراه است. کشف مداوم به شما دردسرهای کاربر می دهد، اما تبدیل آنها به مشخصات بر عهده شماست.

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

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