"این همه چیز را تغییر داد" - مهندسان در 3 پروژه بزرگ پل این را می گویند.

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

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

من مدام همین را از مهندسان ارشد می شنوم: قسمت سخت، ننوشتن کد بیشتر است. داره صدا رو قطع میکنه من با رفع اشکالات دیرهنگام، تاپیک های بررسی طولانی، و دستکاری هایی که مسائل کوچک را به تأخیرهای طولانی تبدیل می کرد، نشسته ام. من همچنین دیده ام که چگونه یک ابزار کوچک، یک گردش کار بهتر، یا یک عادت تیز می تواند سرعت یک تیم را تغییر دهد. به همین دلیل است که افراد با تجربه مهندسی عمیق بسیار صحبت می کنند. آنها درد ضایعات را هر روز احساس می کنند. چیزی که آنها به آن اهمیت می دهند ساده است. آیا می توانم زمان کمتری را برای تکرار همان مراحل صرف کنم؟ آیا تیم من می تواند خطر را زودتر تشخیص دهد؟ آیا می توانیم کار را با پیام های رفت و برگشت کمتر ارسال کنیم؟ آیا می توانیم کیفیت را بدون طولانی کردن کل فرآیند حفظ کنیم؟ این داستان واقعی پشت صحبت است. من به ابزارها توجه نمی کنم زیرا آنها جدید به نظر می رسند. وقتی آنها کاری را که من از قبل خیلی خوب می دانم حل می کنند توجه می کنم. چند هفته پیش، کار تیم محصول کوچکی را در صفحه پرداخت تماشا کردم. کد در یک نگاه خوب به نظر می رسید. اولین آزمون قبول شد. سپس تیکت‌های پشتیبانی دوباره و دوباره همان مشکل را نشان دادند. یک دکمه فعال به نظر می رسید، اما کاربران همچنان در آخرین مرحله گیر می کردند. تیم به هیاهوی بیشتری نیاز نداشت. آنها به راه بهتری برای گرفتن شکاف قبل از آزادی نیاز داشتند. این همان لحظه ای است که مهندسان را وادار به صحبت می کند. وقتی به یک ابزار نگاه می کنم، چند سوال ساده می پرسم. آیا در زمان تکرار کار صرفه جویی می کند؟ آیا با روشی که تیم من در حال حاضر کار می کند مطابقت دارد؟ آیا انسان را در جریان نگه می دارد؟ آیا به من خروجی می دهد که بتوانم به آن اعتماد کنم؟ اگر پاسخ مثبت است، توجه می کنم. من همچنین ابزارهایی را دوست دارم که اصطکاک را کاهش می دهند بدون اینکه از من بخواهند فرآیندم را از ابتدا بازسازی کنم. اگر برای شروع به یک هفته کامل نیاز داشته باشم، به سرعت علاقه ام را از دست می دهم. من چیزی می خواهم که طبیعی باشد. من می خواهم تیمم آن را در یک کار امتحان کند، نتیجه را ببیند و تصمیم بگیرد که آیا کمک می کند یا خیر. در اینجا روشی است که من معمولاً آن را آزمایش می کنم. - من با یک کار شروع می‌کنم که اغلب تکرار می‌شود - جریان قدیمی را با کار جدید مقایسه می‌کنم - بررسی می‌کنم که اشتباهات هنوز در کجا ظاهر می‌شوند - از هم تیمی‌ها بازخورد ساده می‌خواهم - قسمت‌هایی را که کمک می‌کنند نگه می‌دارم و بقیه را رها می‌کنم. این روند را صادقانه نگه می‌دارد. من این رویکرد را در پروژه داشبورد پشتیبانی دیده ام. تیم زمان زیادی را صرف بررسی فیلدهای یکسان در صفحات کرد. پس از اینکه آنها جریان را تغییر دادند و لایه کوچکی از قوانین بررسی را اضافه کردند، تیم زمان کمتری را صرف رفع خطاهای قابل اجتناب کرد. کد جادویی نبود. برد از حذف زباله حاصل شد. به همین دلیل است که مهندسان برتر صحبت می کنند. آنها دنبال سر و صدا نیستند. آنها به دنبال استفاده بهتر از مهارت، عادات مرور بهتر و تمرکز بهتر هستند. آنها می دانند که گردش کار تمیز به آنها فضای بیشتری برای فکر کردن می دهد. این به آنها فضایی می دهد تا قسمت سخت را حل کنند، نه فقط قسمت تکراری را. دیدگاه من ساده است. ابزار نباید جایگزین قضاوت شود. باید از قضاوت محافظت کند. باید از کارهای کوچک و مکرر مراقبت کند تا مهندسان بتوانند انرژی بیشتری را صرف طراحی، کیفیت و انتخاب محصول کنند. اینجاست که ارزش واقعی می نشیند. اگر می شنوید که مهندسان بیشتری در مورد یک روش جدید، یک ابزار یا یک گردش کار صحبت می کنند، آن را نادیده نمی گیرم. می پرسم چه دردی را حل می کند. من آن را روی یک کار آزمایش می کنم. نتیجه را با چشمان باز تماشا می کردم. اینگونه است که من نویز را از کمک جدا می کنم. و به همین دلیل است که صحبت ها بیشتر می شود. ما تجربه گسترده ای در زمینه صنعت داریم. برای مشاوره حرفه ای با ما تماس بگیرید: Wu Lingjie: salesmanager@yyfrank.com.

W. Edwards Deming 1986 Out of the Crisis Eliyahu M. Goldratt 1984 The Goal Jeff Sutherland 2014 Scrum The Art of Doing Twice the Work in Half the Time Gene Kim, Jez Humble, Patrick Debois, and John Willis 2016 The DevOps A. Handbook A20Silingmand از Techniques Designs نمونه‌ها و نکات موردی موسسه مدیریت پروژه 2021 راهنمای مجموعه دانش مدیریت پروژه راهنمای PMBOK