چگونه Fengming زمان تحقیق و توسعه را 30٪ کاهش می دهد (Proof Inside)

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

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

بسیاری از تیم های تحقیق و توسعه قبل از شروع کار واقعی زمان خود را از دست می دهند. مهندسان در میان فایل‌های قدیمی جستجو می‌کنند، الزامات محصول را تأیید می‌کنند، آزمایش‌ها را تکرار می‌کنند و منتظر پاسخ‌های سایر بخش‌ها هستند. یک تاخیر کوچک در هر مرحله می تواند به هفته ها در یک پروژه تبدیل شود. من این مشکل را در پروژه Fengming دیدم. تیم استانداردهای آزمایش را کاهش نداد یا مراحل کلیدی بررسی را حذف نکرد. این روش نحوه انتقال اطلاعات در فرآیند تحقیق و توسعه را تغییر داد. سوابق پروژه نشان داد که تیم حدود 30 درصد زمان کمتری را برای تحقیقات مکرر و هماهنگی معمول صرف کرده است. نتیجه حاصل از چند تغییر عملی بود. ### 1. اطلاعات پروژه را در یک فضای کاری قرار دهید قبل از تغییر، داده های محصول Fengming در سراسر رشته های ایمیل، پوشه های شخصی، صفحات گسترده و پیام های چت پخش می شد. مهندسان اغلب سؤالات مشابهی را بیش از یک بار می پرسند: - کدام نسخه محصول فعلی است؟ - چه کسی آخرین نقاشی را تایید کرد؟ - آیا این ماده تست شده است؟ - بازخورد تامین کننده کجاست؟ این تیم یک فضای پروژه مشترک برای الزامات، نقشه ها، سوابق آزمایشی، یادداشت های تامین کننده و وضعیت تایید ایجاد کرد. هر فایل از یک نام واضح و شماره نسخه استفاده می کرد. فایل های قدیمی برای مرجع نگهداری می شدند اما به عنوان غیرفعال علامت گذاری می شدند. این به مهندسان کمک کرد بدون باز کردن چندین فایل مشابه، سند صحیح را پیدا کنند. هدف ذخیره فایل های بیشتر نبود. هدف کاهش زمان صرف شده برای جستجوی فایل مناسب بود. ### 2. تبدیل کارهای مکرر به قالب های قابل استفاده مجدد برخی از کارهای تحقیق و توسعه هر بار از یک صفحه خالی شروع می شوند. مهندسان طرح های آزمایشی، یادداشت های بررسی و برگه های الزامات را در قالب های مختلف تهیه کردند. این کار ویرایش اضافی ایجاد کرد و مقایسه نتایج را دشوارتر کرد. Fengming الگوهای ساده ای برای کارهای رایج ساخت: - بررسی نیازهای محصول - بررسی مواد - طرح های آزمایش نمونه اولیه - سوابق تغییر طراحی - یادداشت های ارزیابی تامین کننده - نمونه فرم های تایید الگوها جایگزین قضاوت مهندسی نشدند. آنها به تیم نقطه شروع مشترکی دادند. یک مهندس می تواند فرم صحیح را باز کند، جزئیات پروژه را پر کند و به جای بازسازی ساختار سند، بر تصمیمات فنی تمرکز کند. ### 3. ثبت تصمیمات در زمان وقوع یک جلسه می تواند یک ساعت طول بکشد، با این حال تیم ممکن است چندین ساعت دیگر را صرف به خاطر سپردن آنچه تصمیم گرفته شده است صرف کند. Fengming یک رکورد تصمیم گیری کوتاه به هر پروژه اضافه کرد. این شامل: - سوال در حال بررسی - گزینه انتخاب شده - دلیل انتخاب - فرد مسئول برای اقدام بعدی - تاریخ مورد انتظار بررسی این عمل باعث کاهش بحث های مکرر شد. هنگامی که یک عضو جدید تیم به پروژه ملحق شد، آن شخص می‌توانست سوابق تصمیم را بخواند به جای اینکه از چندین همکار بخواهد تاریخچه کامل را توضیح دهند. یک یادداشت کوتاه اغلب در زمان بیشتری نسبت به یک جلسه طولانی صرفه جویی می کند. ### 4. از مراحل بررسی واضح استفاده کنید، زمانی که هر سندی به بازخورد همه نیاز دارد، کار تحقیق و توسعه می تواند کند شود. Fengming نظرات را به مراحل واضح تقسیم کرد. یک جریان معمولی به این صورت بود: 1. مهندس الزامات فنی را بررسی کرد. 2. سرب پروژه هزینه و تاثیر برنامه را بررسی کرد. 3. تیم کیفیت نیازهای تست و انطباق را بررسی کرد. 4. نسخه تایید شده به مرحله بعد منتقل شد. هر فرد می دانست که چه زمانی باید ورودی بدهد و چه زمانی منتظر اطلاعات به روز شود. این باعث کاهش نظرات تکراری شد و به تیم کمک کرد تا از ایجاد تغییرات در یک فایل قدیمی جلوگیری کند. این فرآیند همچنین تشخیص وظایف تاخیری را آسان‌تر کرد. سرنخ پروژه می‌تواند ببیند که آیا این عقب‌نشینی ناشی از داده‌های از دست رفته، آزمایش‌های معلق، یا یک سؤال طراحی بی‌پاسخ است. ### 5. زمان را با تکلیف اندازه گیری کنید، نه با احساس عمومی قبل از تغییر فرآیند، فنگمینگ مدت زمان صرف شده توسط مهندسان را برای فعالیت های رایج ثبت کرد. تیم پیگیری کرد: - جستجو برای اطلاعات پروژه - آماده سازی اسناد تکراری - بررسی نسخه های قدیمی - تکرار جلسات وضعیت - انتظار برای تایید داخلی - کار مجدد اسناد پس از بررسی های نامشخص پس از استفاده از گردش کار جدید، تیم وظایف مشابه را در یک دوره پروژه مشابه مقایسه کرد. کاهش ثبت شده برای هماهنگی معمول تحقیق و توسعه و کار اطلاعاتی مکرر نزدیک به 30 درصد بود. این عدد به این معنی نیست که هر کار مهندسی 30 درصد سریعتر می شود. آزمایشات طراحی، آزمایش و حل مسئله همچنان به زمان عادی خود نیاز داشت. این تمایز مهم است. یک طرح مفید برای صرفه جویی در زمان باید نشان دهد که بهبود در کجا اتفاق افتاده است. یک ادعای گسترده بدون سوابق در سطح وظیفه می تواند انتظارات نادرستی ایجاد کند. ### چه چیزی باعث تفاوت شد Fengming بر یک تغییر بزرگ نرم افزار تکیه نکرد. این بهبود از ترکیب عادات کوچک حاصل شد: - یک مکان برای اطلاعات فعال - نام فایل‌های ثابت - اسناد قابل استفاده مجدد - سوابق تصمیم گیری کوتاه - مراحل بازبینی تعریف شده - ردیابی زمان ساده هر عادت منبع کوچکی از اصطکاک را حذف کرد. آنها با هم، به مهندسان زمان بیشتری برای کار طراحی، آزمایش و بهبودهای مرتبط با مشتری دادند. من اغلب می بینم که شرکت ها به دنبال یک راه حل پیچیده هستند، زمانی که مشکل واقعی گردش کار نامشخص است. یک ابزار جدید ممکن است کمک کند، اما یک ابزار به تنهایی نمی تواند مالکیت از دست رفته، فایل های تکراری یا قوانین بازبینی مبهم را برطرف کند. ### یک راه عملی برای شروع یک تیم می تواند این روش را با یک پروژه فعال آزمایش کند. پروژه ای را انتخاب کنید که بازبینی های مکرر یا تغییرات مکرر سند داشته باشد. میزان زمانی را که تیم در طول یک هفته صرف جستجو، بررسی و بازنویسی اطلاعات می کند را ثبت کنید. یک پوشه یا فضای کاری مشترک ایجاد کنید، در مورد قوانین نامگذاری فایل توافق کنید و دو یا سه الگو را برای کارهای تکراری آماده کنید. پس از دو تا چهار هفته، دوباره سوابق را مرور کنید. بررسی کنید که آیا تیم زمان کمتری را برای هماهنگی صرف می‌کند و آیا مهندسان می‌توانند اطلاعات پروژه را با سؤالات کمتر پیدا کنند. تجربه Fengming نشان می‌دهد که صرفه‌جویی در زمان R&D می‌تواند ناشی از جریان اطلاعات بهتر باشد، نه از کار فنی عجله‌ای. هنگامی که تیم می داند کجا می تواند داده های مناسب را پیدا کند، صاحب هر تصمیم چه کسی است و بعد چه اتفاقی می افتد، پروژه با وقفه های کمتری پیش می رود.

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

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

تاخیرهای تحقیق و توسعه به ندرت از یک مشکل بزرگ ناشی می شود. مشخصات از دست رفته، بازخورد آهسته، مالکیت نامشخص، یا تغییرات مکرر نمونه اولیه می تواند پروژه را از برنامه خارج کند. من دیده ام که تیم ها هفته ها منتظر پاسخ هایی هستند که می توانست در یک جلسه کوتاه حل شود. Fengming با آسان‌تر کردن مسیر توسعه، به این مشکل نزدیک می‌شود. هدف این نیست که در هر کاری عجله کنیم. هدف حذف انتظار قابل اجتناب، کمک به تیم‌ها در تصمیم‌گیری زودتر و تبدیل نتایج مفید آزمایش به اقدام واضح بعدی است. ### با یک خلاصه پروژه مشترک شروع کنید بسیاری از تاخیرها قبل از شروع کار طراحی شروع می شوند. یک تیم مهندسی ممکن است بر عملکرد تمرکز کند. تیم تولید ممکن است بر روی در دسترس بودن مواد تمرکز کند. تیم فروش ممکن است بر نیازهای مشتری تمرکز کند. اگر این نکات در یک خلاصه قرار نگیرند، هر بخش ممکن است با درک متفاوتی از محصول کار کند. من ترجیح می‌دهم اطلاعات اولیه پروژه را در ابتدا تعریف کنم: - هدف محصول - کاربران هدف - الزامات فنی اصلی - شرایط عملیاتی مورد انتظار - محدودیت‌های مواد یا قطعات - نیازهای تست - نقاط تایید - پنجره تحویل برنامه‌ریزی شده این مختصر نیازی به طولانی بودن ندارد. باید آنقدر واضح باشد که هر فرد بتواند از همان مرجع استفاده کند. وقتی یک نیاز تغییر می کند، تیم می تواند بررسی کند که این تغییر چگونه بر طراحی، آزمایش، خرید و تولید تأثیر می گذارد. این عادت ساده می تواند از تبدیل شدن یک تعدیل کوچک به منبع پنهان تاخیر جلوگیری کند. ### وظایف بزرگ را به تصمیم‌های کوچک‌تر تبدیل کنید، در حالی که تصمیم‌های کلیدی باز باقی می‌مانند، یک پروژه ممکن است به جلو حرکت کند. به عنوان مثال، یک تیم محصول ممکن است در حال کار بر روی یک مونتاژ جدید باشد در حالی که انتخاب مواد هنوز قطعی نشده است. طراحی ممکن است کامل به نظر برسد، اما نمونه اولیه نمی تواند به سمت تولید حرکت کند. کار فعال است، اما پروژه در انتظار است. Fengming می تواند این نوع تاخیر را با تقسیم پروژه به نقاط تصمیم کاهش دهد: 1. الزامات محصول را تایید کنید. 2. طرح طراحی را مرور کنید. 3. گزینه های مواد و اجزا را بررسی کنید. 4. نمونه اولیه را بسازید. 5. توابع اصلی را تست کنید. 6. مسائل را ثبت کنید و اقدامات را تعیین کنید. 7. تایید نسخه طراحی بعدی. هر نقطه به تیم یک سوال واضح برای پاسخ دادن می دهد. همچنین باعث می شود مسئولیت راحت تر دیده شود. به نظر من این مفیدتر از درخواست به‌روزرسانی‌های کلی پیشرفت است. "پروژه چگونه پیش می رود؟" ممکن است پاسخی گسترده ایجاد کند. «کدام تأییدیه هنوز باز است؟» منجر به یک اقدام عملی می شود. ### از نمونه های اولیه برای پاسخ دادن به سوالات خاص استفاده کنید یک نمونه اولیه فقط نباید ظاهر محصول را نشان دهد. باید به تیم کمک کند چیزی یاد بگیرد. یک نمونه اولیه مفید ممکن است به سوالاتی مانند: - آیا قطعه با ساختار اطراف تناسب دارد؟ - آیا فرآیند مونتاژ بدون ابزار اضافی انجام می شود؟ - آیا ماده انتخابی بار مورد انتظار را تحمل می کند؟ - آیا نگهداری محصول آسان است؟ - آیا طرح با تجهیزات موجود قابل تولید است؟ یک مثال رایج را می توان در یک محفظه تجهیزات کوچک مشاهده کرد. اولین نمونه ممکن است به درستی جا بیفتد اما مونتاژ آن خیلی طول می کشد. اگر تیم فقط ظاهر را بررسی کند، ممکن است موضوع به مرحله تولید برسد. اگر زمان مونتاژ بخشی از بررسی نمونه اولیه باشد، تیم طراحی می تواند قبل از تولید نمونه های بیشتر، روش بست را تغییر دهد. این رویکرد به هر آزمایش کمک می‌کند تا یک نتیجه واضح ایجاد کند. این تیم قبل از یادگیری از طراحی نیازی به انتظار برای یک نمونه اولیه کامل ندارد. ### بازخورد را نزدیک به کار نگه دارید، تیم های تحقیق و توسعه اغلب زمانی را از دست می دهند که بازخورد از طریق کانال های بیش از حد ارسال می شود. یک طراح ممکن است نقاشی را از طریق ایمیل ارسال کند. یک مهندس تولید ممکن است نظرات خود را در یک فایل جداگانه اضافه کند. یک کارمند خریدار ممکن است اطلاعات مادی را در سیستم دیگری نگهداری کند. وقتی این رکوردها متصل نیستند، افراد ممکن است نسخه قدیمی را مرور کنند یا تغییری را از دست بدهند. یک رکورد پروژه مشترک می تواند شامل موارد زیر باشد: - نسخه نقشه فعلی - داده های تست - سوالات باز - مالک اختصاص داده شده - تاریخ مقرر - وضعیت تایید - دلیل هر تغییر طراحی قالب می تواند ساده باشد. یک صفحه گسترده مشترک، پلت فرم پروژه، یا سیستم اسناد کنترل شده ممکن است برای یک تیم کوچک کافی باشد. آنچه مهم است کنترل نسخه است. همه باید بدانند که کدام فایل جاری است و کدام عملکرد هنوز باز است. ### به هر تأخیر یک مالک واضح بدهید، زمانی که کسی مالک مرحله بعدی باشد، تاخیر آسان‌تر حل می‌شود. این به معنای سرزنش یک نفر نیست. این به معنای تعیین اینکه چه کسی پاسخ را ارائه می دهد، چه کسی آن را بررسی می کند و چه کسی نتیجه را تایید می کند. به عنوان مثال: - مهندسی تغییر طراحی را تایید می کند. - چک خرید در دسترس بودن تامین کننده. - کیفیت روش تست را تعریف می کند. - تولید فرآیند مونتاژ را بررسی می کند. - مدیر پروژه تصمیم را پیگیری می کند. جلسه پروژه زمانی مفیدتر می شود که هر آیتم باز با مالک و یک اقدام خاص به پایان برسد. "مواد را بررسی کنید" خیلی گسترده است. "خرید نمره موجود و زمان تحویل را تا چهارشنبه تایید می کند" به تیم چیزی برای پیگیری می دهد. ### پیشرفت را از طریق خروجی مفید اندازه گیری کنید یک پروژه ممکن است جلسات زیادی داشته باشد و همچنان نتایج کمی داشته باشد. من به نشانه های عملی پیشرفت نگاه می کنم: - یک الزام تایید شده است. - یک نقاشی بررسی شده است. - یک نمونه آزمایشی را تکمیل کرده است. - یک مشکل یک علت ثبت شده دارد. - تغییر یک مالک اختصاص یافته دارد. - تصمیمی تصویب شده است. این علائم نشان می دهد که آیا تیم از بحث به عمل در حال حرکت است یا خیر. رویکرد Fengming می‌تواند با اتصال هر مرحله با یک خروجی واضح، از نتایج سریع‌تر پشتیبانی کند. این همه مشکلات فنی را برطرف نمی کند. این به تیم راه بهتری برای یافتن مشکلات زودهنگام و پاسخگویی بدون از دست دادن کنترل پروژه می دهد. ### از هر چرخه توسعه بیاموزید یک پروژه با تاخیر نباید با تحویل عجولانه و بدون بررسی پایان یابد. پس از یک نمونه اولیه یا چرخه آزمایش، می‌پرسم: - کدام کار طولانی‌ترین مدت را منتظر ماند؟ - کدام الزام تغییر کرد؟ - کدام آزمون مفیدترین اطلاعات را داد؟ - کدام تایید نامشخص بود؟ - کدام مشکل ممکن است در پروژه بعدی ظاهر شود؟ پاسخ ها می توانند خلاصه پروژه بعدی، روند بررسی و طرح آزمایشی را بهبود بخشند. یک فرآیند تحقیق و توسعه سریعتر با رد کردن چک ها ایجاد نمی شود. این از انجام بررسی‌های صحیح زودتر، قابل مشاهده نگه داشتن اطلاعات و کمک به هر تیم بر اساس حقایق مشابه ناشی می‌شود. اینگونه است که Fengming می‌تواند تاخیرهای تحقیق و توسعه را به مسیر کنترل‌شده‌تری برای رسیدن به نتایج تبدیل کند: کار را به وضوح تعریف کنید، با هدف آزمایش کنید، تصمیم‌ها را دنبال کنید و مسئولیت را نزدیک به هر کار باز نگه دارید. با ما در xiongguilin تماس بگیرید: hbfmkj@fengmingsmart.cn/WhatsApp +8613510239313.

Fengming Smart Technology 2024 Fengming R&D گزارش بهبود گردش کار تیم مدیریت مهندسی Fengming 2024 سوابق بهینه سازی فرآیند توسعه محصول سوابق بخش کیفیت Fengming 2024 بررسی تغییر طراحی و آزمایش نمونه اولیه دفتر مدیریت پروژه Fengming دفتر مدیریت پروژه 2024 تحقیق و توسعه چرخه تحقیق و توسعه زمان اندازه گیری خلاصه عملیات 2024 و راهنمای گردش کار تایید بخش توسعه محصول Fengming 2024 مدیریت اطلاعات فنی و تجزیه و تحلیل کاهش مجدد کار