مهندسان برتر چه می دانند که شما نمی دانید؟

بسیاری از مردم فکر می کنند مهندسی قوی از دانستن ابزارهای بیشتر، نوشتن کدهای بیشتر یا حل سریعتر معادلات دشوار ناشی می شود. تجربه من به من می گوید که مهارت سخت تر این است که قبل از ایجاد راه حل، مشکل درست را انتخاب کنید. یک سیستم می تواند سریع باشد و همچنان از کار بیفتد. یک محصول می تواند جذاب به نظر برسد و همچنان کاربران را ناامید کند. یک طرح می تواند یک آزمون را پشت سر بگذارد و در صورت تغییر شرایط همچنان شکسته شود. مهندسان باتجربه چه چیزی را درک می کنند که دیگران ممکن است از دست بدهند؟ آنها یاد می گیرند که تصمیمات فنی را با نیازهای کاربر، محدودیت های سیستم، ارتباطات تیمی و نگهداری طولانی مدت مرتبط کنند. آنها با مهندسی به عنوان مسابقه ای برای تولید خروجی بیشتر برخورد نمی کنند. آنها با آن به عنوان راهی برای کاهش خطر و ایجاد نتایج مفید رفتار می کنند. آنها قبل از انتخاب ابزار مشکل را تعریف می کنند وقتی پروژه ای مبهم به نظر می رسد، من با یک سوال ساده شروع می کنم: "ما در تلاشیم چه مشکلی را حل کنیم؟" این سوال از بسیاری از تصمیمات ضعیف جلوگیری می کند. یک تیم ممکن است درخواست یک برنامه جدید تلفن همراه داشته باشد، در حالی که مشکل واقعی فرآیند تأیید کند است. یک مدیر ممکن است یک داشبورد درخواست کند، در حالی که کارمندان فقط به یک گزارش هفتگی قابل اعتماد نیاز دارند. می نویسم: - مشکل کیست؟ - وقتی مشکل ادامه پیدا می کند چه اتفاقی می افتد؟ - امروزه مردم چگونه با آن برخورد می کنند؟ - چه نتیجه ای نشان می دهد که راه حل کمک می کند؟ - تیم باید چه محدودیت هایی را رعایت کند؟ این فرآیند نیازی به سند طولانی ندارد. بیان مشکل کوتاه می تواند هفته ها کار را راهنمایی کند. به عنوان مثال، یک شرکت تحویل کوچک ممکن است معتقد باشد که برای برنامه ریزی مسیرها به هوش مصنوعی نیاز دارد. پس از بررسی روند آن، تیم ممکن است متوجه شود که رانندگان جزئیات آدرس ناقص را دریافت می کنند. بهبود ورود داده ها می تواند ارزش بیشتری نسبت به افزودن یک سیستم پیش بینی پیچیده داشته باشد. مهندسی خوب اغلب با رفع سردرگمی شروع می شود. آنها با طرح های ساده با احترام برخورد می کنند نگهداری بسیاری از سیستم ها سخت می شود، زیرا هر ویژگی جدید لایه دیگری از منطق را اضافه می کند. تیم اصلی ممکن است طراحی را درک کند، اما یک مهندس جدید می تواند برای تغییر یک قسمت کوچک بدون ایجاد خطاهای جدید تلاش کند. من ساختارهای ساده را زمانی ترجیح می دهم که بتوانند نیاز را برآورده کنند. ساده به معنای بی دقتی نیست. این بدان معنی است که هر بخش کار روشنی دارد، جریان داده به راحتی قابل پیگیری است و تیم می تواند انتخاب های اصلی را توضیح دهد. یک طراحی ساده ممکن است شامل موارد زیر باشد: - ماژول‌های کوچک با مسئولیت‌های واضح - نام‌هایی که هدف را توصیف می‌کنند - چند وابستگی پنهان - یک فرآیند راه‌اندازی کوتاه - آزمایش‌هایی برای رفتار کلیدی - یادداشت‌های مکتوب برای تصمیم‌هایی که ممکن است تیم‌های آینده را گیج کند یک عملکرد کوتاه همیشه بهتر از یک عملکرد طولانی نیست. سوال مفید این است که آیا مهندس دیگری می تواند آن را با تلاش معقول درک کرده و تغییر دهد؟ آنها مفروضات را زود آزمایش می کنند یک طرح اغلب حاوی حدس هایی در مورد کاربران، ترافیک، سخت افزار، هزینه و زمان پاسخ است. مشکلات زمانی ظاهر می شوند که حدس ها پنهان می مانند. من دوست دارم هر فرض اصلی را به یک آزمون کوچک تبدیل کنم. اگر تیمی معتقد است که کاربران یک فرم را در دو دقیقه تکمیل می‌کنند، چند نفر را در استفاده از آن مشاهده کنید. اگر انتظار می رود یک سرویس ده هزار درخواست در دقیقه انجام دهد، نسخه ایمن آن بار را قبل از راه اندازی آزمایش کنید. اگر حسگر باید در محیط سرد کار کند، آن را در خارج از دفتر تست کنید. آزمون نیازی به کامل بودن ندارد. نیاز به تولید اطلاعات مفید دارد. این رویکرد به مهندسان ناسا کمک کرد تا از انواع ابهامات در طول مأموریت‌های فضایی اجتناب کنند، با این حال یک شکست معروف نشان می‌دهد که وقتی یک فرض اساسی از قلم افتاده چه اتفاقی می‌افتد. مدارگرد آب و هوای مریخ در سال 1999 پس از استفاده تیم های نرم افزاری از واحدهای اندازه گیری مختلف گم شد. یک گروه با ثانیه های پوند نیروی کار می کردند، در حالی که گروهی دیگر انتظار داشتند ثانیه های نیوتنی. فضاپیما در مسیر اشتباهی در اطراف مریخ وارد شد. درس این نیست که هر پروژه به جلسات بیشتری نیاز دارد. درس این است که تیم ها به تعاریف مشترک برای مقادیر، قالب ها، واحدها و محدودیت ها نیاز دارند. آنها برای خرابی طراحی می کنند یک سیستم نباید به عملکرد کامل هر قسمت وابسته باشد. شبکه ها قطع می شوند باتری ها قدرت خود را از دست می دهند. افراد اطلاعات نادرست وارد می کنند. سرورها بیش از حد بارگذاری می شوند. تامین کننده یک جزء را تغییر می دهد. می پرسم: - اگر این سرویس متوقف شود چه اتفاقی می افتد؟ - آیا کاربر می تواند دوباره با خیال راحت امتحان کند؟ - آیا سیستم داده ها را از دست می دهد؟ - آیا تیم می تواند مشکل را ببیند؟ - آیا فرآیند دستی برای موارد فوری وجود دارد؟ به عنوان مثال، یک سرویس پرداخت باید یک بازه زمانی شبکه را بدون دوبار هزینه از مشتری انجام دهد. یک اسکنر انبار باید یک پیام واضح را هنگام قطع اتصال ارائه دهد. یک دستگاه پزشکی باید خطا را به گونه ای گزارش کند که به کارکنان آموزش دیده کمک کند تا پاسخ دهند. برنامه ریزی شکست پیش بینی فاجعه نیست. این راهی برای محافظت از کاربران از سردرگمی قابل اجتناب است. آنها از داده ها بدون فراموش کردن قضاوت استفاده می کنند اندازه گیری ها به مهندسان کمک می کند تا الگوها را ببینند. آنها جایگزین تفکر نمی شوند. یک تیم ممکن است سرعت صفحه، نرخ خطا، هزینه تولید یا درخواست های پشتیبانی مشتری را ردیابی کند. این اعداد می توانند نشان دهند که کجا باید جستجو کرد، اما هر معیار دارای محدودیت هایی است. تعداد کمتر بلیط های پشتیبانی می تواند به معنای بهبود محصول باشد. همچنین می تواند به این معنی باشد که کاربران منصرف شده و از درخواست کمک خودداری می کنند. من به اعداد در کنار نظرات کاربران، گزارش‌ها، گزارش‌های میدانی و مشاهدات مستقیم نگاه می‌کنم. یک متریک به من می گوید چه اتفاقی افتاده است. زمینه به توضیح علت کمک می کند. این تعادل زمانی اهمیت دارد که یک شرکت بخواهد محصولی را بهبود بخشد. دکمه ای با نرخ کلیک بالاتر ممکن است فعالیت بیشتری را به همراه داشته باشد، اما مرحله بعدی ممکن است سردرگمی ایجاد کند. اندازه‌گیری سفر کامل کاربر، دید بهتری نسبت به تمرکز روی یک عدد می‌دهد. آنها نه تنها نتایج، بلکه تصمیمات را به هم منتقل می کنند کارهای فنی بر افرادی تأثیر می گذارد که ممکن است کد را نخوانند یا معماری سیستم را درک نکنند. من سعی می کنم تصمیمات را به زبان ساده توضیح دهم: - چه چیزی را انتخاب کردیم؟ - چی رو رد کردیم؟ - چه معامله ای را پذیرفتیم؟ - چه خطری باقی می ماند؟ - اگر شرایط تغییر کند چه اتفاقی باید بیفتد؟ یک رکورد کوتاه تصمیم گیری می تواند ماه ها بعد در زمان صرفه جویی کند. همچنین می تواند تیم را از تکرار یک بحث قدیمی جلوگیری کند. ارتباط شفاف نیازی به حذف تمام جزئیات فنی ندارد. یعنی قرار دادن جزئیات درست در جای مناسب. یک مشتری ممکن است نیاز داشته باشد بداند که تاخیر چگونه بر تحویل کالا تأثیر می گذارد. یک مهندس ممکن است نیاز داشته باشد که قانون زمان وقفه دقیق را بداند. ممکن است یک مدیر نیاز به درک هزینه و ریسک داشته باشد. هر فرد به یک دیدگاه مفید نیاز دارد. آنها فضایی را برای نگهداری باقی می گذارند محصول وقتی به دست کاربران می رسد تمام نمی شود. مهندسان باید آن را نظارت کنند، آن را تعمیر کنند، وابستگی ها را به روز کنند، به سوالات پاسخ دهند و آن را با شرایط جدید تطبیق دهند. من کارهای تعمیر و نگهداری را در طرح اصلی گنجانده ام: - مالک سرویس چه کسی است؟ - خطاها چگونه گزارش خواهند شد؟ - وابستگی ها هر چند وقت یکبار بررسی خواهند شد؟ - چه اطلاعاتی به مهندس بعدی کمک خواهد کرد؟ - احتمال تغییر کدام قسمت ها وجود دارد؟ سیستمی که در طول توسعه یک هفته صرفه جویی می کند اما ماه ها تعمیر را صرف می کند، می تواند یک معامله ضعیف ایجاد کند. بهترین طراحی از افرادی پشتیبانی می کند که پس از حرکت تیم اصلی، آن را اجرا می کنند. آنها مدام از شکست های کوچک یاد می گیرند مهندسان قوی عاری از اشتباه نیستند. آنها عادت هایی می سازند که اشتباهات را آسان تر پیدا کرده و تکرار آن را کم هزینه تر می کند. پس از یک حادثه، من فقط از پرسیدن «چه کسی خطا کرد؟» اجتناب می‌کنم. می پرسم: - چه چیزی خطا را ممکن کرد؟ - کدام سیگنال را از دست دادیم؟ - چه بخشی از فرآیند باعث تشویق به اشتباه شد؟ - چه تغییر کوچکی می تواند شانس تکرار را کاهش دهد؟ این سبک بررسی به جای سرزنش، اقدام مفیدی ایجاد می کند. یک چک لیست واضح تر، یک آزمایش خودکار، یا یک پیش فرض ایمن تر ممکن است بعداً از بروز مشکل مشابه جلوگیری کند. عاداتی که مهندسی خوب را شکل می دهند، عملی هستند: تعریف مشکل، آزمون فرضیات، قابل فهم نگه داشتن طرح ها، برنامه ریزی برای شکست، برقراری ارتباط بین انتخاب ها، و پشتیبانی از سیستم پس از راه اندازی. ابزارها تغییر خواهند کرد. زبان های برنامه نویسی تغییر خواهند کرد. ساختار تیم تغییر خواهد کرد. نیاز به تفکر دقیق باقی خواهد ماند. وقتی یک تصمیم مهندسی را قضاوت می‌کنم، فراتر از تاثیرگذار بودن راه‌حل نگاه می‌کنم. من می‌پرسم که آیا این یک نیاز واقعی را برطرف می‌کند، آیا مردم می‌توانند آن را درک کنند، و آیا تیم می‌تواند از آن حمایت کند وقتی شرایط دیگر ایده‌آل نیست.

بسیاری از مهندسان این تئوری را می‌دانند، اما پروژه‌ها هنوز با تاخیر، الزامات نامشخص، اشکالات مکرر و دوباره کاری پرهزینه مواجه می‌شوند. من این اتفاق را دیده ام زمانی که یک تیم قبل از اینکه مشکل را بفهمد شروع به ساختن می کند. مهندسان قوی متفاوت کار می کنند. آنها سوالات بهتری می پرسند، ایده های کوچک را آزمایش می کنند، تصمیمات را مستند می کنند و نیازهای کاربر را در نظر می گیرند. این عادات به عنوان شغلی یا شخصیت خاصی بستگی ندارد. آنها را می توان در یک پروژه نرم افزاری، یک کار طراحی محصول یا یک طرح بهبود کارخانه تمرین کرد. در اینجا پنج عادتی است که من اغلب در مهندسانی که نتایج ثابت و مفیدی ارائه می دهند می بینم. 1. آنها قبل از انتخاب راه حل مشکل را تعریف می کنند درخواستی مانند "سیستم را سریع تر کنید" واضح به نظر می رسد، اما چندین سوال را بی پاسخ می گذارد: - کدام بخش کند به نظر می رسد؟ - چه کسی تحت تأثیر قرار می گیرد؟ - تأخیر چند وقت یکبار اتفاق می افتد؟ - چه سطحی از سرعت قابل قبول است؟ - آیا تغییر می تواند در جای دیگر مشکل جدیدی ایجاد کند؟ من یک بار روی فرآیندی کار کردم که در آن تیمی قصد داشت یک ابزار کند را جایگزین کند. پس از بررسی داده ها، متوجه شدیم که تاخیر اصلی از مرحله تایید دستی ناشی می شود، نه خود ابزار. یک تغییر کوچک در جریان تایید زمان انتظار را بدون نیاز به تعویض کامل سیستم کاهش داد. مهندسان خوب برای نشان دادن اینکه می توانند چیزی بسازند عجله نمی کنند. آنها مطمئن می شوند که مشکل درست را حل می کنند. یک بیان مشکل ساده می تواند کمک کند: "کاربران باید ___ را تکمیل کنند، اما در حال حاضر با ___ مشکل دارند، که باعث ___ می شود." این قالب به تیم یک نقطه مرجع مشترک می دهد. همچنین تشخیص مفروضات ضعیف را آسان تر می کند. 2. آنها وظایف بزرگ را به تست های کوچک تقسیم می کنند پروژه های بزرگ اغلب دشوار به نظر می رسند، زیرا بسیاری از مجهولات با هم مخلوط می شوند. یک مهندس ممکن است نداند که مشکل از کد، سخت افزار، داده یا جریان کاربر است. من ترجیح می دهم آن مجهولات را جدا کنم و آنها را یکی یکی آزمایش کنم. برای یک ویژگی نرم افزار، ممکن است به این صورت باشد: 1. تأیید کنید که داده ها در دسترس هستند. 2. قانون اصلی کسب و کار را با یک نمونه کوچک تست کنید. 3. نحوه رفتار سیستم با داده های از دست رفته را بررسی کنید. 4. زمان پاسخ را اندازه گیری کنید. 5. از یک کاربر بخواهید کار را کامل کند. 6. نتیجه را با تیم مرور کنید. قبل از اینکه تیم هفته ها را صرف ساخت کامل کند، یک تست کوچک بازخورد مفیدی را ارائه می دهد. اگر آزمون ناموفق باشد، تیم زودتر یاد می‌گیرد، زمانی که ایجاد تغییرات آسان‌تر است. این عادت همچنین به کنترل هزینه پروژه کمک می کند. یک آزمون کوتاه می تواند نشان دهد که یک رویکرد برنامه ریزی شده نامناسب است. این اطلاعات مفیدی است، نه کار بیهوده. 3. آنها شکست را به عنوان اطلاعات در نظر می گیرند یک آزمون ناموفق می تواند احساس ناامیدی داشته باشد، به خصوص زمانی که افراد زمان خود را صرف آماده کردن آن کرده باشند. مهندسان قوی نتیجه را پنهان نمی کنند یا کسی را که مشکل را پیدا کرده است سرزنش نمی کنند. آنها می پرسند که نتیجه چه چیزی به تیم می آموزد. کار توماس ادیسون در مورد روشنایی الکتریکی اغلب مورد بحث قرار می گیرد زیرا شامل آزمایش های زیادی می شود. درس مفید ادعایی در مورد تعداد مشخصی از تلاش ها نیست. درس این است که آزمایش مکرر می تواند گزینه های ضعیف را حذف کند و درک را بهبود بخشد. در یک پروژه محل کار، شکست ممکن است کوچکتر باشد: - یک سنسور خوانش های ناپایدار می دهد. - یک صفحه در یک دستگاه کار می کند اما در دستگاه دیگر نه. - استفاده از نمونه اولیه دشوار است. - پرس و جو پایگاه داده با مجموعه داده های بزرگتر کند می شود. هر نتیجه به یک سوال اشاره می کند. آیا طراحی اشتباه است؟ آیا تنظیمات تست ناقص است؟ آیا شرط نامشخص است؟ من دوست دارم سه جزئیات را پس از یک آزمون ناموفق ثبت کنم: - آنچه ما انتظار داشتیم - آنچه مشاهده کردیم - آنچه در آینده تغییر خواهیم کرد این باعث می شود بحث بر روی شواهد متمرکز شود. همچنین از تکرار یک آزمون بدون یادگیری از آن تیم جلوگیری می کند. 4. آنها انتخاب های فنی را به زبان ساده توضیح می دهند تصمیمات مهندسی بر افرادی تأثیر می گذارد که ممکن است کد بنویسند، نقشه های فنی را نخوانند یا محدودیت های سیستم را درک نکنند. یک مهندس قوی می تواند یک انتخاب را بدون پنهان شدن در پشت عبارات دشوار توضیح دهد. به جای گفتن: "معماری برای بهبود مقیاس پذیری نیاز به پردازش ناهمزمان دارد." ممکن است بگویم: "اگر این سیستم در پس‌زمینه وظایف را پردازش کند، دسته‌های بزرگ را راحت‌تر انجام می‌دهد. کاربران می‌توانند تا زمانی که کارها کامل شده‌اند به کار خود ادامه دهند." توضیح دوم به افراد اطلاعات کافی برای بحث در مورد مبادله می دهد. همچنین جای سوال باقی می گذارد. ارتباط شفاف به معنای حذف تمام جزئیات فنی نیست. به این معنی است که به هر فرد جزئیاتی که نیاز دارد داده شود. ممکن است یک مدیر پروژه نیاز به درک هزینه، زمان، ریسک و تأثیر کاربر داشته باشد. یک توسعه دهنده ممکن است به قوانین داده و جزئیات رابط نیاز داشته باشد. ممکن است یک مشتری نیاز داشته باشد بداند چه چیزی در صفحه نمایش او تغییر خواهد کرد. من همچنین سعی می کنم محدودیت ها را زودتر توضیح دهم. اگر طرحی نتواند از هر ویژگی درخواستی پشتیبانی کند، این را می گویم و گزینه های موجود را توضیح می دهم. این از اعتماد محافظت می کند و به تیم فرصتی می دهد تا با اطلاعات بهتر انتخاب کند. **5. آنها بازخورد را در کار ایجاد می کنند ** مهندسان می توانند زمان طولانی را صرف بهبود راه حلی کنند که کاربران به آن نیاز ندارند. بازخورد منظم این خطر را کاهش می دهد. بازخورد می‌تواند از منابع زیادی باشد: - مصاحبه کوتاه با کاربر - بررسی طراحی - آزمایش نمونه اولیه - یک بلیط پشتیبانی - یک گزارش تولید - همکار که در ساخت شرکت نداشته است در یک شرکت نرم‌افزاری کوچک، یک تیم یک بار داشبورد گزارش دقیقی ایجاد کردند. این طرح در بررسی های داخلی مفید به نظر می رسید، اما مشتریان به ندرت از بیشتر فیلترها استفاده می کردند. یک جلسه کوتاه مشتری نشان داد که کاربران عمدتاً دو عدد و راهی برای صادرات آنها می خواهند. تیم صفحه را ساده کرد و کار روزانه را آسانتر کرد. آن مثال نحوه رویکرد من به کار محصول را تغییر داد. من دیگر با بازخورد به عنوان مرحله تایید نهایی برخورد نمی کنم. من به دنبال آن هستم در حالی که تغییر ایده هنوز آسان است. یک سوال بازخورد مفید این است: "چه چیزی شما را از استفاده از این باز می دارد؟" اغلب پاسخ های مفیدتری نسبت به "دوست داری؟" افراد ممکن است از یک طراحی لذت ببرند، اما همچنان آن را کند، گیج کننده، یا به سختی در روال خود قرار می دهند. این پنج عادت با هم کار می کنند. یک مشکل واضح منجر به آزمایش های متمرکز می شود. آزمایش های کوچک شواهد ایجاد می کنند. شواهد از تصمیمات فنی بهتر پشتیبانی می کنند. زبان ساده به تیم بزرگتر کمک می کند تا آن تصمیمات را درک کند. بازخورد منظم کار را به نیازهای کاربر متصل نگه می دارد. من یک مهندس را فقط بر اساس مقداری که می تواند بسازد قضاوت نمی کنم. من همچنین به نحوه فکر کردن آنها در هنگام نامشخص بودن شرایط، نحوه واکنش آنها در هنگام شکست در یک آزمون و اینکه آیا می توانند به دیگران در انتخاب صحیح کمک کنند، نگاه می کنم. یک عادت مهندسی مفید می تواند با یک پروژه شروع شود. مشکل را در یک جمله بنویسید. یک تست کوچک انجام دهید. اتفاقی که افتاده را ثبت کنید. تصمیم را به زبان ساده توضیح دهید. قبل از اینکه احساس کنید کار تمام شده است، از یک کاربر بازخورد بخواهید. این فرآیند ممکن است هر چالشی را برطرف نکند، با این حال به تیم راه روشن تری برای رسیدگی به آنها می دهد.

بسیاری از مردم سعی می کنند با تلاش بیشتر مشکلات را حل کنند. من از یک رویکرد متفاوت استفاده می کنم: سرعتم را کم می کنم، مشکل را تعریف می کنم و به دنبال علت می گردم. این طرز تفکر به من کمک می‌کند از تصمیم‌های عجولانه، کار بیهوده و راه‌حل‌هایی که فقط برای مدت کوتاهی موضوع را پنهان می‌کنند، اجتناب کنم. در مهندسی، تجارت، نرم افزار، طراحی محصول و کارهای روزانه کار می کند. وقتی پروژه ای دشوار است، از خودم یک سوال می پرسم: ** یک مهندس قبل از تغییر هر چیزی چه چیزی را بررسی می کند؟** 1. مسئله را در یک جمله تعریف کنید یک مسئله مبهم اقدامات مبهم ایجاد می کند. «فروش کم است» به اندازه کافی به من نمی گوید. باید بپرسم: - کدام محصول فروش کمتری دارد؟ - تغییر از چه زمانی شروع شد؟ - کدام مشتریان تحت تأثیر قرار می گیرند؟ - آیا موضوع مربوط به ترافیک، قیمت، اعتماد یا فرآیند خرید است؟ بیانیه بهتر ممکن است این باشد: "بازدیدکنندگان تلفن همراه به صفحه پرداخت می رسند، اما بسیاری از آنها قبل از تکمیل سفارش خارج می شوند." این جمله به من مکان روشنی برای شروع می دهد. همچنین از تغییر همزمان محصول، قیمت و تبلیغات من جلوگیری می کند. 2. حقایق را از حدس ها جدا کنید من اغلب می بینم که تیم ها حدس ها را به عنوان واقعیت در نظر می گیرند. یک مدیر ممکن است بگوید: "مشتریان قیمت را دوست ندارند." داده ها ممکن است داستان متفاوتی را نشان دهند. بازدیدکنندگان ممکن است آنجا را ترک کنند زیرا صفحه پرداخت به کندی بارگیری می شود، هزینه حمل و نقل دیر ظاهر می شود یا فرم درخواست اطلاعات زیادی می کند. من دو لیست ساده ایجاد می کنم: ** حقایق ** - ترافیک در ماه گذشته افزایش یافته است. - بیشتر بازدیدکنندگان از دستگاه های تلفن همراه استفاده می کنند. - بسیاری از کاربران در صفحه پرداخت ترک می کنند. ** حدس ها ** - قیمت ممکن است بالا باشد. - فرم تسویه حساب ممکن است خیلی طولانی باشد. - مشتریان ممکن است انتخاب های پرداخت بیشتری بخواهند. این عادت کوچک کیفیت بحث را تغییر می دهد. حقایق راهنمای بررسی بعدی است. حدس ها به جای تصمیم گیری تبدیل به سوال می شوند. 3. علت اصلی را پیدا کنید یک مشکل قابل مشاهده همیشه مشکل واقعی نیست. فرض کنید ماشینی در یک شیفت کاری متوقف می شود. با تعویض یک قطعه ممکن است دوباره کار شود. یک مهندس همچنین می پرسد که چرا قطعه از کار افتاده است. من از روش "چرا" استفاده می کنم: - چرا دستگاه متوقف شد؟ موتور بیش از حد گرم شد. - چرا موتور بیش از حد گرم شد؟ هوا نمی توانست از منطقه خنک کننده عبور کند. - چرا جریان هوا مسدود شد؟ گرد و غبار فیلتر را پوشانده است. - چرا فیلتر پر از گرد و غبار بود؟ برنامه نظافت مشخص نبود. اولین پاسخ به موتور اشاره می کند. علت عمیق تر ممکن است تعمیر و نگهداری ضعیف باشد. من برای همیشه از "چرا" نمی پرسم. زمانی که پاسخ منجر به عملی شود که می تواند از بازگشت همان مشکل جلوگیری کند، متوقف می شوم. 4. مشکلات بزرگ را به آزمون های کوچک تقسیم کنید تغییرات بزرگ ریسک بیشتری را به همراه دارد. تست های کوچک با ضایعات کمتر بازخورد مفیدی به من می دهند. اگر بخواهم صفحه پرداخت را بهبود بخشم، کل فروشگاه را به یکباره بازسازی نمی کنم. من ممکن است یک تغییر را آزمایش کنم: - هزینه کل را زودتر نشان دهید. - دو فیلد فرم را حذف کنید. - گزینه پرداخت مهمان را اضافه کنید. - بهبود طرح موبایل. - تعداد مراحل پرداخت را کاهش دهید. من یک معیار اصلی مانند سفارشات تکمیل شده را دنبال می کنم. من تغییرات دیگر را در طول آزمایش ثابت نگه می دارم. این به من کمک می کند تا بفهمم چه چیزی باعث نتیجه شده است. یک آزمایش کوچک ممکن است تغییر چشمگیری ایجاد نکند. که هنوز مفید است. یک نتیجه ضعیف به من می گوید که کدام مسیر به توجه کمتری نیاز دارد. 5. طراحی برای استفاده واقعی یک ایده می تواند روی کاغذ خوب به نظر برسد و همچنان در طول استفاده روزانه شکست بخورد. مهندسان در مورد شخص، مکان، ابزارها و محدودیت های پیرامون یک سیستم فکر می کنند. من وقتی محصول یا فرآیندی را بررسی می‌کنم از همان نمای استفاده می‌کنم. برای پرداخت تلفن همراه می پرسم: - آیا شخصی می تواند صفحه را در نور روشن بخواند؟ - آیا فرم با یک دست کار می کند؟ - وقتی اتصال اینترنت ضعیف است چه اتفاقی می افتد؟ - آیا کاربر می تواند یک خطا را بدون شروع مجدد تصحیح کند؟ - آیا صفحه توضیح می دهد که بعد از پرداخت چه اتفاقی می افتد؟ یک مثال واقعی در بسیاری از اشکال آنلاین ظاهر می شود. هنگامی که رمز عبور رد می شود، پیامی مانند "ورودی نامعتبر" کمک چندانی نمی کند. پیامی مانند "از حداقل هشت کاراکتر و یک عدد استفاده کنید" به شخص کمک می کند مشکل را برطرف کند. طراحی خوب حدس و گمان را کاهش می دهد. 6. انتظار شکست را داشته باشید و پاسخی را آماده کنید یک سیستم قوی سیستمی نیست که هرگز شکست نخورد. زمانی که مشکلی پیش بیاید، مسیری روشن به مردم می دهد. می پرسم: - چه چیزی ممکن است شکست بخورد؟ - چگونه متوجه آن خواهم شد؟ - چه کسی باید پاسخ دهد؟ - کاربر باید چه چیزی را ببیند؟ - آیا سیستم می تواند به حالت امن بازگردد؟ فرآیند تحویل ممکن است با آدرس گم شده، بسته آسیب دیده یا تاخیر پرداخت مواجه شود. یک پیام روشن و یک مسیر پشتیبانی ساده می تواند از تبدیل شدن یک موضوع کوچک به یک شکایت جدی جلوگیری کند. این طرز فکر همچنین کار تیمی را بهبود می بخشد. مردم مشکلات را زودتر گزارش می دهند، زمانی که هدف این است که به جای سرزنش یک نفر، آن را اصلاح کنند. 7. دلیل پشت هر تصمیمی را که یادداشت های کوتاهی درباره آن نگه می دارم یادداشت کنید: - مشکلی که دیدم - شواهدی که استفاده کردم - گزینه هایی که بررسی کردم - آزمایشی که انتخاب کردم - نتیجه - اقدام بعدی این یادداشت ها به زمانی که پروژه تغییر می کند کمک می کند. آنها همچنین تیم را از تکرار بحث های قدیمی محافظت می کنند. گزارش تصمیم گیری نیازی به گزارش های طولانی ندارد. چند جمله واضح اغلب کافی است. 8. بهبود سیستم، نه تنها نتیجه یک اصلاح موقت می تواند یک گزارش را بهتر جلوه دهد در حالی که علت باقی است. اگر پشتیبانی مشتری هر روز یک سوال مشابه را دریافت می کند، اضافه کردن کارکنان پشتیبانی بیشتر ممکن است برای مدت کوتاهی کمک کند. یک مسیر بهتر ممکن است بهبود دستورالعمل های محصول، به روز رسانی صفحه راهنما یا تغییر صفحه گیج کننده باشد. من به دنبال کارهای تکراری، خطاهای مکرر و سوالات مکرر هستم. آن‌ها اغلب نشان می‌دهند که فرآیند به کجا نیاز دارد. بهترین عادت های مهندسی ساده هستند: مشکل را تعریف کنید. حقایق را بررسی کنید. به دنبال علت باشید. یک تغییر را تست کنید. مراقب نحوه استفاده مردم از نتیجه باشید. برای شکست آماده شوید. یک رکورد نگه دارید. روند را بهبود بخشید. برای استفاده از این روش نیازی به مهندس بودن ندارم. وقتی با یک کار دشوار روبرو می شوم، نظرات سریع را با سوالات واضح جایگزین می کنم. این تغییر به من کمک می کند تا انتخاب های بهتری داشته باشم، استدلال خود را توضیح دهم و راه حل هایی بسازم که فراتر از یک لحظه کار کنند.

بسیاری از تیم‌ها می‌خواهند سریع‌تر بسازند، اما سرعت اغلب باعث ایجاد دوباره کاری می‌شود. یک برنامه شتابزده می تواند منجر به وظایف نامشخص، نیازهای مشتری از دست رفته و ویژگی هایی شود که نگهداری از آنها ماه ها طول می کشد. من متوجه شده ام که ساختمان هوشمندتر با تصمیمات بهتر شروع می شود، نه روزهای کاری طولانی تر. ### با مشکل واقعی کاربر شروع کنید قبل از اینکه برای یک محصول، خدمات یا کمپین برنامه ریزی کنم، مشکل را در یک جمله می نویسم. به عنوان مثال: > «فروشگاه‌های آنلاین کوچک سفارشات خود را از دست می‌دهند زیرا مشتریان نمی‌توانند هزینه‌های تحویل را قبل از تسویه‌حساب ببینند». این بیانیه به تیم یک جهت روشن می دهد. مفیدتر از این است که بگویید: «ما به تجربه خرید بهتری نیاز داریم». سپس مشکل را از طریق مصاحبه با مشتری، پیام‌های پشتیبانی، داده‌های جستجو یا تماس‌های فروش بررسی می‌کنم. یک مکالمه کوتاه با پنج کاربر می تواند مسائلی را آشکار کند که یک جلسه داخلی طولانی ممکن است از دست برود. ### نسخه اول را کوچک نگه دارید نسخه اول باید یک مشکل واضح را حل کند. به همه ویژگی های موجود در لیست آرزوها نیاز ندارد. این نیاز به یک مسیر مفید از نیاز مشتری به یک نتیجه عملی دارد. یک تیم تسویه حساب ممکن است با موارد زیر شروع شود: - هزینه های تحویل را پاک کنید - فرم کوتاه تر - پرداخت سازگار با موبایل - تایید سفارش ساده تیم می تواند امتیازات وفاداری، گزارش های پیشرفته و ابزارهای طراحی سفارشی را برای مرحله بعدی بگذارد. این باعث می شود کار آسان تر آزمایش شود و راحت تر تغییر کند. ### ایده ها را به وظایف قابل مشاهده تبدیل کنید اهداف بزرگ می توانند بدون نشان دادن پیشرفت واقعی باعث شوند تیم ها احساس مشغله کنند. من هر هدف را به وظایفی تقسیم می کنم که کسی می تواند آنها را تکمیل و مرور کند. به جای نوشتن: > "بهبود وب سایت" از کارهایی مانند: - مرور پنج صفحه محصول پربازدید - حذف فیلدهای فرم مکرر - اضافه کردن اطلاعات تحویل نزدیک به قیمت - تست صفحه در سه اندازه صفحه نمایش معمولی - مقایسه سفارشات تکمیل شده قبل و بعد از تغییر - پاک کردن وظایف به افراد کمک می کند ببینند چه اتفاقی باید بیفتد. آنها همچنین تشخیص تاخیر را آسان تر می کنند. ### یک حلقه بازخورد کوتاه بسازید من قبل از جمع‌آوری بازخورد منتظر راه‌اندازی کامل نیستم. یک نسخه کار ساده را می توان به گروه کوچکی از کاربران نشان داد. سوالات آنها اغلب مشکلاتی را آشکار می کند که تیم ندیده است. آمازون علناً درباره تیم‌های کوچک و مستقل و آزمایش‌های اولیه به عنوان بخشی از فرهنگ کاری خود بحث کرده است. درس مفید این است که هر قسمت از آن مدل را کپی نکنید. این برای روشن نگه داشتن مالکیت و ارائه بازخورد مشتری به فرآیند قبل از صرف زمان زیاد است. ### نتایج مفید را اندازه گیری کنید. برای یک صفحه محصول، می‌توانم موارد زیر را ردیابی کنم: - نرخ افزودن به سبد خرید - تکمیل تسویه‌حساب - سوالات مشتری - درخواست‌های بازپرداخت - زمان بارگذاری صفحه یک معیار به ندرت کل داستان را بیان می‌کند. نرخ کلیک بالاتر ممکن است مثبت به نظر برسد، اما اگر مشتریان بیشتری در حین پرداخت آن را ترک کنند، معنای کمی دارد. من داده ها را با نظرات مشتریان بررسی می کنم. اعداد نشان می دهد که چه چیزی تغییر کرده است. مکالمات اغلب توضیح می دهند که چرا. ### کارهایی را که به مشتری کمک نمی کند حذف کنید برخی از کارها ادامه دارند زیرا یک تیم همیشه آنها را انجام داده است. من یک سوال ساده می پرسم: > "این کار به ما کمک می کند تا چه تصمیمی بگیریم؟" اگر گزارش هفتگی توسط کسی استفاده نشود، ممکن است نیاز به تغییر قالب داشته باشد. اگر جلسه ای تصمیم روشنی نداشته باشد، ممکن است یک سند مشترک بهتر عمل کند. اگر یک ویژگی نیاز کاربر شناخته شده ای نداشته باشد، ممکن است به پارکینگ تعلق داشته باشد. این به معنای مراقبت یا کیفیت برش نیست. این به معنای توجه به کاری است که از یک نتیجه واقعی پشتیبانی می کند. ### بهبود را به بخشی از روال تبدیل کنید بعد از هر انتشار، سه نکته را مرور می کنم: - چه چیزی به پیشرفت کار کمک کرد؟ - مردم کجا منتظر ماندند یا کار را تکرار کردند؟ - در چرخه بعدی چه چیزی را باید تغییر دهیم؟ یک بررسی کوتاه می‌تواند منجر به تنظیم عملی شود، مانند یادداشت‌های طراحی واضح‌تر، آزمایش‌های اولیه یا مراحل تأیید کمتر. ساختن هوشمندانه‌تر و سریع‌تر به معنای سوق دادن مردم به کار بدون مکث نیست. این در مورد کاهش حدس و گمان، روشن نگه داشتن دامنه و یادگیری است در حالی که تغییر کار هنوز آسان است. وقتی تیم‌ها روی یک مشکل مشتری تمرکز می‌کنند، ایده‌های کوچک را آزمایش می‌کنند و نتایج مفید را اندازه‌گیری می‌کنند، پیشرفت آسان‌تر دیده می‌شود و حفظ آن آسان‌تر می‌شود.

بسیاری از مردم می‌خواهند آنچه را که کارشناسان می‌دانند بیاموزند، اما اغلب با ویدیوهای پراکنده، پست‌های کوتاه و توصیه‌هایی شروع می‌کنند که با نیازهایشان مطابقت ندارد. نتیجه آشناست: یادداشت های فراوان، پیشرفت اندک، و هیچ راه روشنی برای قضاوت در مورد مفید بودن یادگیری وجود ندارد. من یک راه ساده تر را ترجیح می دهم. من نگاه می کنم که افراد ماهر چگونه فکر می کنند، چگونه تصمیم می گیرند و در صورت شکست یک طرح چگونه واکنش نشان می دهند. دانش تخصصی فقط فهرستی از حقایق نیست. راهی برای دیدن مشکلات است. ### 1. با یک مشکل واضح شروع کنید کارشناسان به ندرت بدون دلیل یاد می گیرند. آنها معمولاً با سؤالی مانند این شروع می کنند: - چرا مشتریان یک سرویس را ترک می کنند؟ - چرا یک محصول بازدید می کند اما فروش کمی دارد؟ - چرا یک تیم همان اشتباه را تکرار می کند؟ - چرا یک طرح مطالعه پس از چند روز از کار می افتد؟ یک مسئله واضح به یادگیری جهت عملی می دهد. وقتی مشکل را تعریف می‌کنم، می‌توانم اطلاعاتی را که جالب به نظر می‌رسند، اما به من در تصمیم‌گیری بهتر کمک نمی‌کنند، نادیده بگیرم. یک سوال مفید این است: "پس از یادگیری این موضوع چه کاری باید انجام دهم؟" پاسخ ممکن است یک مهارت، یک تصمیم یا یک فرآیند باشد. ### 2. تصمیمات مطالعه، نه تنها نتایج افراد مبتدی اغلب به یک نتیجه موفق نگاه می کنند و سعی می کنند آن را کپی کنند. کارشناسان به انتخاب های پشت آن نتیجه توجه می کنند. دو فروشگاه اینترنتی را تصور کنید که محصولات مشابهی را می فروشند. یک فروشگاه فروش بالایی دارد. کپی کردن رنگ‌ها، طرح‌بندی یا عکس‌های محصول ممکن است نتیجه یکسانی نداشته باشد. دلیل واقعی ممکن است اطلاعات واضح تر محصول، پشتیبانی بهتر از مشتری، یا روند بازگشت روان تر باشد. وقتی یک مثال قوی را مطالعه می کنم، می پرسم: - آن شخص با چه مشکلی روبرو بود؟ - چه گزینه هایی در دسترس بود؟ - کدام انتخاب را کردند؟ - چه اطلاعاتی این انتخاب را شکل داد؟ - بعد از تصمیم چه شد؟ - حالا چه چیزی را تغییر می دهند؟ این روش به من کمک می کند به جای کپی کردن جزئیات سطح، یک فرآیند را یاد بگیرم. ### 3. به دنبال الگوهای تکراری باشید یک مثال می تواند مفید باشد، اما ممکن است غیرعادی نیز باشد. من به دنبال همین ایده در چندین منبع معتبر هستم. به عنوان مثال، بسیاری از نویسندگان با تجربه از عادت کاری مشابهی استفاده می کنند: 1. قبل از نوشتن، خواننده را تعریف می کنند. 2. سوالات کاربران واقعی را جمع آوری می کنند. 3. آنها یک ایده اصلی را در یک زمان توضیح می دهند. 4. جملاتی را حذف می کنند که خواننده را حمایت نمی کند. 5. آنها پس از دیدن اینکه مردم چگونه پاسخ می دهند، تجدید نظر می کنند. جمله بندی از نویسنده ای به نویسنده دیگر تغییر می کند. الگو باقی می ماند. آزمایش الگوهای تکراری آسان تر است. من می توانم یک تغییر کوچک اعمال کنم، نتیجه را تماشا کنم و تصمیم بگیرم که آیا با شرایط من مطابقت دارد یا خیر. ### 4. بدون کپی کردن آسیب از اشتباهات درس بگیرید کارشناسان از هر اشتباهی اجتناب نمی کنند. آنها هزینه اشتباهات را کاهش می دهند و با دقت از آنها درس می گیرند. صنعت هوانوردی یک مثال مفید ارائه می دهد. خلبان ها از چک لیست ها برای کاهش گام های از دست رفته در کارهای پیچیده استفاده می کنند. بیمارستان ها همچنین چک لیست های جراحی را برای حمایت از ارتباطات و ایمنی اتخاذ کردند. چک لیست جایگزین مهارت نمی شود. هنگامی که افراد خسته، عجله دارند یا به جزئیات زیادی دست می زنند، از توجه محافظت می کند. من از همین ایده در کارهای کوچکتر استفاده می کنم. قبل از انتشار یک صفحه، ممکن است بررسی کنم: - آیا صفحه به یک سوال واضح پاسخ می دهد؟ - آیا خواننده می تواند پیشنهاد را بدون حدس زدن درک کند؟ - آیا حقایق با اطلاعات موثق پشتیبانی می شوند؟ - آیا صفحه روی گوشی به خوبی کار می کند؟ - آیا عمل بعدی به راحتی قابل درک است؟ یک چک لیست کوتاه می تواند از تأثیر اشتباهات ساده بر کل نتیجه جلوگیری کند. ### 5. سوالات بهتری بپرسید دسترسی به کارشناسان همیشه به معنای دسترسی به یادگیری مفید نیست. یک سوال مبهم اغلب پاسخی مبهم ایجاد می کند. به جای اینکه بپرسید "چگونه می توانم بازاریابی خود را بهبود بخشم؟" می توانم بپرسم: - کدام بخش از سفر مشتری بیشترین افراد را از دست می دهد؟ - چه شواهدی نشان می دهد که این صفحه نیاز به تغییرات دارد؟ - کدام پیام باعث سردرگمی می شود؟ - چه تست کوچکی را می توانم بدون تغییر کل کمپین اجرا کنم؟ - چه نتیجه ای نشان می دهد که این تغییر کمک کرده است؟ سوالات خوب تفکر پشت پاسخ را آشکار می کند. آنها همچنین مقایسه توصیه ها از منابع مختلف را آسان تر می کنند. ### 6. در واحدهای کوچک تمرین کنید خواندن در مورد یک مهارت باعث ایجاد آشنایی می شود. تمرین نشان می دهد که آیا می توانم از آن استفاده کنم یا خیر. اگر در حال یادگیری محتوای جستجو هستم، می توانم یک صفحه را انتخاب کنم و تمرکز، ساختار و زبان آن را بهبود ببخشم. اگر در حال یادگیری فروش هستم، می‌توانم یک مکالمه مشتری را بررسی کنم و نقطه‌ای را که مشتری در آن نامطمئن شده است، شناسایی کنم. اگر در حال یادگیری طراحی هستم، می‌توانم دو طرح‌بندی صفحه را با هم مقایسه کنم و توضیح دهم که چرا استفاده از یک صفحه راحت‌تر است. تمرین کوچک بازخورد ایجاد می کند. بازخورد اطلاعات را به دانش کاری تبدیل می کند. ### 7. یک رکورد تصمیم را نگه دارید به نظر من نوشتن سه یادداشت کوتاه مفید است: - آنچه قبل از انجام کار به آن اعتقاد داشتم - آنچه را تغییر دادم - آنچه بعد از تغییر اتفاق افتاد این رکورد مرا از قضاوت یک روش تنها با حافظه باز می دارد. همچنین نشان می‌دهد که چه ایده‌هایی با مخاطب، بودجه، ابزار و سبک کار من مناسب است. روشی که به یک شرکت بزرگ کمک می کند ممکن است برای یک تجارت کوچک مناسب نباشد. یک روال مطالعه که برای یک فرد موثر است ممکن است برای دیگری شکست بخورد. دانش تخصصی زمانی مفید می شود که آن را در برابر شرایط خودم آزمایش کنم. ### یک برنامه یادگیری عملی من می توانم از این روال ساده استفاده کنم: 1. یک مشکل خاص را انتخاب کنید. 2. چندین نمونه قابل اعتماد پیدا کنید. 3. تصمیمات پشت هر مثال را مطالعه کنید. 4. به الگوهایی که بیش از یک بار ظاهر می شوند توجه کنید. 5. یک تغییر کوچک را آزمایش کنید. 6. نتیجه را ثبت کنید. 7. روش را تنظیم کنید و روند را تکرار کنید. این رویکرد به صبر نیاز دارد، اما تلاش تصادفی را کاهش می دهد. همچنین روش بهتری برای قضاوت درباره نصیحت به من می دهد. من نیازی به پیروی از هر نظر عمومی ندارم. من باید دلیل یک روش را بفهمم، آن را با دقت آزمایش کنم و آنچه مفید است را حفظ کنم. یادگیری آنچه که متخصصان می‌دانند، کمتر در مورد جمع‌آوری اطلاعات بیشتر است. این در مورد دیدن مشکلات با دقت بیشتر، انتخاب با شواهد بهتر و ایجاد عاداتی است که با تمرین به بهبود ادامه می‌دهند. امروز با ما تماس بگیرید تا بیشتر بدانید JennyHU: Jennyhu@jh-products.com/WhatsApp ++8618913784194.

استیو کروگ (2014) من را وادار به فکر نکنید که دوباره فردریک پی بروکس جونیور (1995) ژن اسطوره ای مرد-ماه کیم کوین بهر و جورج اسپافورد (2013) پروژه ققنوس دلیل جیمز (1997) مدیریت خطرات ناشی از حوادث اداری سازمانی (99) گزارش فاز اول هیئت بررسی اشتباه مدارگرد آب و هوا، اریک ریس (2011) راه اندازی ناب