مهندسی نرم‌افزار - بخش‌های نرم

این مطلب ترجمه‌ی کتاب Software Engineering - The Soft Parts از Addy Osmani است.

پیشگفتار

امروز می‌خواهم برخی از “مهارت‌های نرم” مهندسی نرم‌افزار را که در طول ۱۰ سال اول کار خود در گوگل کروم، جایی که مدیر ارشد مهندسی هستم، یاد گرفته‌ام با شما به اشتراک بگذارم. در دهمین سالگرد کارم، می‌خواستم به برخی از درس‌هایی که با من مانده‌اند بیندیشم. امیدوارم این‌ها در طول دوران حرفه‌ای شما مفید واقع شوند.

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

پیشاپیش می‌گویم که من نه مهم، نه حکیم و نه اصیل هستم. ممکن است تجربه شما متفاوت باشد :)

با تشکر ویژه از لینا سوهونی، جاشوا کروز، کارا اریکسون، جف پاسنیک، حسین جیرده و سریرام کریشنان برای بازخورد و مشارکت مهربانانه آنها در این کتاب.

درباره نویسنده

ادی عثمانی مدیر ارشد مهندسی در گوگل است که بر روی کروم کار می‌کند.

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

شما می‌توانید ادی را در توییتر و لینکدین پیدا کنید.

یادگیری چیزهای جدید

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

تسلط

تسلط فنی به معنای نسبت بالای ارزش تحویل داده شده به ساعات کار است.

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

اغلب از من پرسیده می‌شود، “چگونه بدانم از زمانم بهترین استفاده را می‌کنم؟”. تقریباً همیشه کارهایی وجود خواهند داشت که می‌توانید وقت خود را با آنها پر کنید تا “احساس” مشغول بودن کنید. ترفند واقعی اینجاست که مطمئن شوید روی چیزهای درست کار می‌کنید. اگر می‌خواهید کوه‌ها را جابجا کنید، روی کارهایی تمرکز کنید که عقربه را حرکت می‌دهند، حتی اگر آن حرکت کوچک باشد.

چند سؤال می‌توانید از خود بپرسید:

• اهداف من چیست؟ آیا کارهایی که روی آنها تمرکز کرده‌ام با این اهداف همسو هستند؟
• آیا چیزی هست که بتوانم متفاوت یا بهتر انجام دهم؟

حتی پرسیدن چنین سؤالاتی از خود می‌تواند فوق‌العاده قدرتمند باشد.

تفکر انتقادی و تدوین استدلال‌های منطقی

تفکر انتقادی توانایی استفاده از مهارت‌های شناختی برای فکر کردن مستقل به منظور تصمیم‌گیری‌های اندیشمندانه است. در این مهارت سرمایه‌گذاری کنید تا وضوح فکری خود را بهبود بخشید.

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

به طور کلی، برخی از سؤالاتی که بر اساس تفکر انتقادی دوست دارم بپرسم عبارتند از:

• چگونه می‌دانیم مشکل درستی را حل می‌کنیم؟
• چگونه می‌دانیم مشکل را به روش درستی حل می‌کنیم؟ (یعنی ایجاد تعادل بین دقت و کارآیی، با توجه به درک ما از مشکل و محدودیت‌ها)
• اگر منابع مشکل خود را نمی‌دانیم، چگونه می‌توانیم علت اصلی را تعیین کنیم؟
• چگونه می‌توانیم سؤال کلیدی را به سؤال‌های کوچکتری که می‌توانیم بیشتر تحلیل کنیم، تقسیم کنیم؟
• وقتی یک یا چند فرضیه داریم، چگونه کار را ساختاربندی کنیم تا آنها را ارزیابی کنیم؟
• اگر تحت محدودیت‌ها (فشار زمانی) قرار داریم، چه میانبرهایی می‌توانیم بزنیم بدون اینکه بیش از حد به دقت تحلیلی خود در مورد سؤال لطمه بزنیم؟
• آیا شواهد به اندازه کافی از نتیجه‌گیری‌ها پشتیبانی می‌کنند؟
• چگونه می‌دانیم چه زمانی کار تمام شده است؟ چه زمانی راه‌حل “به اندازه کافی خوب” است؟
• چگونه راه‌حل را به طور واضح و منطقی به همه ذینفعان انتقال دهم؟

من دریافته‌ام که این سؤالات اغلب کمک می‌کنند. گاهی اوقات ما به علائم یک مشکل می‌پردازیم، فقط برای اینکه کشف کنیم علائم دیگری هم وجود دارند. در مواقع دیگر، ممکن است راه‌حلی را سریعاً ارائه دهیم که در آینده مشکلات بیشتری ایجاد کند. با تمرکز بر تفکر انتقادی، ممکن است فرضیات را به چالش بکشیم، به ریسک/منفعت دقیق‌تر نگاه کنیم، به دنبال شواهد متناقض باشیم، اعتبار را ارزیابی کنیم و به دنبال داده‌های بیشتری برای ایجاد اطمینان باشیم که کار درستی انجام می‌دهیم.

به عنوان مثال، یک اشتباه رایج که دیده‌ام مهندسان مرتکب می‌شوند این فرض است که همبستگی نشان‌دهنده علیت است (یعنی صرفاً به این دلیل که دو چیز با هم همبستگی دارند، لزوماً به این معنی نیست که یکی باعث دیگری می‌شود). یک متفکر انتقادی ممکن است فرضیاتی مانند این را به چالش بکشد و بپرسد چرا ما باور داریم که آنها درست هستند.

متفکران انتقادی:

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

توجه: تفکر انتقادی هم جنبه‌های “مهارت نرم” و هم “مهارت سخت” را دارد، بنابراین در این نوشته گنجانده شده است.

ایجاد یک پایه قوی

اصول پایه را به خوبی فرا بگیرید و آنها را مکرراً به کار ببرید تا مهارت‌های جدید کسب کنید.

ارزش بلندمدت یادگیری اصول پایه این است که آنها قابل انتقال هستند. در کوتاه مدت، آنها به شما کمک می‌کنند تا تصمیمات بهتری بگیرید و می‌توانند کد را کارآمدتر کنند.

مهارت‌های قابل انتقال

مهارت‌های قابل انتقال مهارت‌هایی هستند که می‌توانید از یک پروژه به پروژه دیگر با خود ببرید. بیایید درباره آنها در رابطه با اصول پایه صحبت کنیم.

اصول پایه، اساس هر حرفه مهندسی نرم‌افزار هستند. دو لایه برای آنها وجود دارد - کلان و خرد. لایه کلان هسته مهندسی نرم‌افزار است و لایه خرد مربوط به پیاده‌سازی است (مانند استک فناوری، کتابخانه‌ها، فریم‌ورک‌ها و غیره).

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

در سطح خرد، شما پیاده‌سازی آن مفاهیم را می‌آموزید. این می‌تواند شامل مواردی مانند: زبانی که استفاده می‌کنید (جاوااسکریپت، پایتون، روبی و غیره)، فریم‌ورک‌هایی که استفاده می‌کنید (مانند React، Angular، Vue و غیره)، بک‌اندی که استفاده می‌کنید (مانند Django، Rails و غیره) و استک فناوری که استفاده می‌کنید (مانند Google App Engine، Google Cloud Platform و غیره) باشد. اینها جزئیاتی هستند که می‌توانند برای کسب تخصص در آنها ارزشمند باشند تا موثر باشید، اما همیشه قابل انتقال نیستند.

با یادگیری اصول پایه، مهارت‌ها و ابزارهایی به دست می‌آورید که سپس می‌توانید اصول پایه را نادیده بگیرید و رشد کنید.

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

کارایی

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

تصمیم‌گیری بهتر

داشتن درک خوبی از اصول پایه کلان و خرد می‌تواند به شما کمک کند تا تصمیمات بهتری بگیرید.

می‌توانید از دانشی که کسب کرده‌اید برای گرفتن تصمیمات بهتر در مورد اینکه کدام فناوری‌ها را استفاده کنید و از کدام‌ها بر اساس اهداف و محدودیت‌های هر پروژه اجتناب کنید، استفاده کنید. این می‌تواند به شما کمک کند تا از دام‌های انتخاب فناوری نادرست یا ابزار نامناسب برای کار اجتناب کنید.

“شما یک ابزار را به طور کامل نشناخته‌اید تا زمانی که بفهمید چه زمانی نباید از آن استفاده کرد.” - @kelseyhightower

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

مطالعات مرتبط:

• ارزش اصول پایه در مهندسی نرم‌افزار (https://bit.ly/softskills-value)
• چرا یادگیری اصول پایه مهم است (https://bit.ly/softskills-funmatter)
• یادگیری اصول پایه یک ذهنیت خوب توسعه‌دهنده (https://bit.ly/softskills-mindset)

تمرکز بر کاربر و بقیه دنبال خواهد آمد

با تجربه کاربر شروع کنید و به عقب به سمت فناوری مورد نیاز کار کنید.

استیو جابز زمانی به طور معروف گفت: “شما باید با تجربه مشتری شروع کنید و به عقب به سمت فناوری کار کنید. شما نمی‌توانید با فناوری شروع کنید و سپس سعی کنید بفهمید کجا می‌توانید آن را بفروشید.”

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

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

بهترین نرم‌افزار توسط مهندسانی ساخته می‌شود که برای کاربران خود همدلی دارند.

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

ارتقاء مهارت‌های خود

آنچه برای مورد استفاده شما مناسب است را انتخاب کنید، نه مد روز ماه.

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

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

از پروژه‌های جدید برای یادگیری فناوری جدید استفاده کنید.

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

کنجکاو باشید و هرگز از یادگیری دست نکشید

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

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

برای رهبران قدرتمند است که اعتراف کنند وقتی چیزی را نمی‌دانند.

داشتن این اعتماد به نفس، انتظار اینکه مهندسان ارشد باید همه چیز را بدانند را کاهش می‌دهد. شما مطلقاً نیازی ندارید همه پاسخ‌ها را بدانید، اما توانایی اعتراف به اینکه انسان هستید و متعهد به یافتن راهی برای حل مشکلات با تیم خود هستید، بخش مهم است.

رهبران همچنین اعتراف می‌کنند وقتی اشتباه می‌کنند.

مهم است که به تیم خود یاد دهید چگونه با اشتباهات با فروتنی و تمایل به یادگیری و بهبود برخورد کنند. دنیای واقعی کامل نیست و کاملاً مشکلی ندارد که به تیم خود نشان دهید کامل نیست تا آنها را برای آن آماده کنید.

یک مراقب باشید، نه یک مالک.

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

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

عمق و گستره مهارت‌ها

در نظر بگیرید آیا جک همه فن‌ها بودن و استاد یکی از آنها بودن برای شما مناسب است.

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

من شخصاً ایده مهندسان T-Shaped را دوست دارم (https://bit.ly/softskills-tshaped). اینها مهندسانی هستند که در یک یا تعداد کمی مهارت متخصص عمیق هستند (میله عمودی T)، اما درک اساسی از بسیاری مهارت‌های دیگر مورد نیاز برای ساخت و اجرای یک محصول دارند (میله افقی). برخی تیم‌ها دوست دارند اعضای تیم را در محدوده‌ای از تخصص‌های مختلف بچرخانند تا اعضای تیم T-Shaped بیشتری بسازند.

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

تجربه کردن یعنی یادگرفتن

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

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

همانطور که در اینجا ذکر شده (https://bit.ly/softskills-notcode)، “ارزش اصلی در نرم‌افزار نه کدی که تولید شده، بلکه دانشی است که توسط افرادی که آن را تولید کرده‌اند انباشته شده است”. با این حال، لطفاً هنگام آزمایش با فناوری جدید، در محیط تولید آزمایش نکنید.

پیچیدگی فنی

کد عمومی در مقابل کد خاص

کد را به طور خاص برای مشکل مورد نظر بنویسید، اما سعی کنید مکان‌هایی را پیدا کنید که می‌توانید آن را کمی عمومی کنید.

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

چندین اصل وجود دارند که معمولاً درباره پیچیدگی طراحی بحث می‌شوند. از دنیای برنامه‌نویسی حد نهایی، شما دارید:

• YAGNI یا شما نیازی به آن نخواهید داشت، که بیان می‌کند برنامه‌نویسان نباید عملکردی را تا زمانی که ضروری باشد اضافه کنند (https://bit.ly/softskills-yagni)
• ساده‌ترین کاری که می‌تواند کار کند را انجام دهید - برای پیشرفت سریع به جای برنامه‌ریزی برای آینده (https://bit.ly/softskills-simplest)

هر دو این اصول هدفشان جلوگیری از بیش‌مهندسی است (https://bit.ly/softskills-overeng). با این حال، این اصول می‌توانند برای ایجاد چندین راه‌حل ساده که به خوبی با هم یکپارچه نمی‌شوند، مورد سوء استفاده قرار گیرند.

در سوی دیگر طیف، شما اصل انتزاع (https://bit.ly/softskills-abstraction) را دارید که هدف آن کاهش ساختارهای تکراری در کد هر زمان که عملی است از طریق انتزاع و تعمیم. من ترجیح می‌دهم بین انتزاع شدید و سادگی شدید، راه میانه را با کمی عمومی‌تر کردن کد انتخاب کنم. اصل AHA (اجتناب از انتزاع‌های عجولانه) ایده مشابهی را ترویج می‌کند (https://bit.ly/softskills-aha).

ماژول‌های عمیق

کدی بنویسید که مشکلات پیچیده را برای سایر توسعه‌دهندگان حل کند اما عملکرد را از طریق یک رابط واضح ارائه دهد.

اگر شما یک طراح یا توسعه‌دهنده API هستید - مسئولیت شما ارائه یک رابط برای ساده‌سازی عملکرد پیچیده برای سایر توسعه‌دهندگان است. اگر رابط بیش از حد دشوار برای درک باشد و هزینه‌ای را به برنامه‌نویسی که از آن استفاده می‌کند تحمیل کند، هدف شکست می‌خورد. این ایده در مفهوم ماژول‌های عمیق منعکس شده است - “بهترین ماژول‌ها آنهایی هستند که بیشترین مزیت و کمترین هزینه را دارند. مزیت ارائه شده توسط یک ماژول عملکرد آن است، و هزینه یک ماژول رابط آن است.” (https://bit.ly/softskills-deepmodules).

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

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

یادگیری در یک پروژه نگهداری

هنگام کار بر روی کد قدیمی در سیستم‌های قدیمی‌تر، تفاوت بین کدی که باید بماند و کدی که باید برود را درک کنید.

هر مهندس ارشدی باید تلاش کند تا تفاوت بین کدی که باید بماند و کدی که باید برود را درک کند.

سیستم‌های تولیدی بزرگ و طولانی مدت برخی کدهای بد یا کدهایی که دیگر دلیل خوبی برای ماندن ندارند، خواهند داشت. سالم است که درک کنید چرا چیزی وجود دارد (دلیل خوب؟ دلیل بد؟). کد بد را حذف کنید و کد خوب را نگه دارید.

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

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

یادگیری در یک پروژه سبز (جدید)

آزمایش کنید، نوآوری کنید، سریع شکست بخورید و در حل مسائل بهتر شوید.

سفر یادگیری شما کاملاً متفاوت است وقتی با ساخت یک سیستم از صفر روبرو می‌شوید. هنگامی که شروع به نمونه‌سازی یا پیاده‌سازی ویژگی‌ها به صورت تکراری می‌کنید، یاد می‌گیرید چه چیزی کار می‌کند و چه چیزی کار نمی‌کند. متدولوژی چابک و اصل شکست سریع به شما کمک می‌کنند تا ایده‌های خود را زودتر با منابع کمتری اعتبارسنجی کنید (https://bit.ly/softskills-failfast). آنها به شما امکان می‌دهند مشکلات پیچیده را تقسیم و فتح کنید.

تعریف انجام‌شده

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

اصل دیگر چابک که هنگام مقابله با پیچیدگی مفید است، توافق بر تعریف انجام‌شده است (https://bit.ly/softskills-done). علاوه بر برآوردن نیازهای کاربر و معیارهای پذیرش، این می‌تواند شامل شرایط دیگری مانند بررسی‌های کد، آزمایش، مستندسازی و غیره باشد.

استقرار مرحله‌ای

یک انتشار بزرگ واحد ممکن است به یک سری استقرارهای با ریسک کمتر و درک خوب تقسیم شود.

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

اشکال‌زدایی سیستماتیک

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

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

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

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

ارتباطات

اهمیت مستندات طراحی

مستندات طراحی نباید یک فکر بعدی باشد بلکه بخش جدایی‌ناپذیری از فرآیند مهندسی نرم‌افزار باشد.

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

فرآیند مستندسازی

برای سند طراحی بررسی‌ها را هماهنگ کنید و طراحی را همانطور که تکامل می‌یابد با سند اصلی مقایسه کنید تا تأیید کنید که تمام محدودیت‌های مربوطه مورد توجه قرار گرفته‌اند.

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

ارتباطات

فروتن باشید، به وضوح ارتباط برقرار کنید و به دیگران احترام بگذارید. مهربان بودن هزینه‌ای ندارد، اما تأثیر آن بی‌بها است. برخی ممکن است بگویند ارتباط خوب هزینه انرژی و تفکر دارد. باید انرژی بیشتری برای همدلی باشد.

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

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

ارتباط سفارشی

از زبان، مفاهیم و سطوح جزئیات مرتبط با مخاطب خود استفاده کنید.

صرف‌نظر از سطح درک ما از یک مشکل یا وضعیت، هنگامی که آن را با دیگران بحث می‌کنیم، باید کلمات خود را طوری تنظیم کنیم که آنها بتوانند سریعاً آنچه برای آنها مرتبط است را درک کنند:

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

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

مهربانی و ملاحظه‌کاری

مهربان بودن یک ابرقدرت است - از آن استفاده کنید.

آرام، مهربان و مفید بودن می‌تواند شما را فراتر از قطع کردن کسی ببرد. با افراد داخل تیم خود مهربان باشید زیرا این به ایجاد تیم قوی‌تر و موفق‌تر کمک می‌کند. با افراد خارج از تیم خود نیز دوستانه باشید. با تمام بخش‌های سازمان خود (منابع انسانی، مالی یا بازاریابی) با احترام برابر رفتار کنید. ممکن است مستقیماً به آنها کمک نکنید، اما همیشه می‌توانید کار آنها را درک کنید و با آنها همدردی کنید. وقتی دیگران کار خوبی انجام داده‌اند یا تقدیر دریافت کرده‌اند، به آنها تبریک بگویید یا از آنها قدردانی کنید. مهربانی مسری است (https://bit.ly/softskills-contag). افرادی که با آنها مهربان بوده‌اید، احتمالاً به هر درخواست کمکی در آینده پاسخ می‌دهند.

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

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

قدرت نه

گفتن نه بهتر از بیش از حد متعهد شدن است.

بیشتر ما در گفتن “نه” وقتی صحبت از کار بیشتر است، خوب نیستیم. این یا به این دلیل است که آنها متوجه نمی‌شوند که ‘نه’ یک گزینه است، یا ما از چالش لذت می‌بریم. با این حال، تعهد بیش از حد یک مسئولیت است زیرا می‌تواند منجر به تأخیر شود. اجازه دادن به طرف مقابل برای دانستن آنچه قبلاً روی میز شماست و ارائه یک تخمین منطقی از مدت زمانی که طول می‌کشد، نشانه احترام است. این به طرف دیگر فرصتی می‌دهد تا گزینه‌های خود را در نظر بگیرد - از شخص دیگری بخواهد یا زمان‌بندی خود را تمدید کند. مدیریت از شما نخواهد خواست چیزی را در زمان رکورد تحویل دهید اگر بدانند که این به طور قابل توجهی بر کیفیت محصول تأثیر خواهد گذاشت. اگر یک مدیر ارشد هستید، تیم خود را قدرت بدهید تا به ایده‌های بد نه بگویند (https://bit.ly/softskills-empower).

“یک توسعه‌دهنده ارشد (یا هر فرد مولد) در گفتن نه خوب است. مردم بیش از آنچه می‌توانید وقت بگذارید، از زمان شما خواهند خواست. شما می‌توانید به آرامی اما قاطعانه نه بگویید، افراد را به جای دیگری هدایت کنید (واگذار کنید)، یا از افراد بخواهید با مدیر شما در مورد اینکه آیا زمان بیشتری از شما برای کمک به آنها اختصاص داده شود، صحبت کنند.” (https://news.ycombinator.com/item?id=18131722)

شما نمی‌توانید همه را راضی کنید - هنگام گفتن “بله” در مقابل “نه” بسیار هوشیار باشید.

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

پذیرش و احترام

وقتی چیزی را نمی‌دانید، اعتراف کنید و برای درخواست کمک، حتی از جوان‌ترها، باز باشید.

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

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

اشتراک اطلاعات

از جلسات و جلسات پرسش و پاسخ برای پرسیدن سؤالات درست، تبادل دانش و اطلاع رسانی به تیم استفاده کنید.

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

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

انعطاف‌پذیری

از نظرات خود قاطعانه دفاع کنید اما هر بار که شواهد جدیدی دارید که آنها را نقض می‌کند، آنها را بررسی کنید.

گوش دادن به نظرات دیگران بخش کلیدی ارتباط است. این ضروری است زیرا ممکن است بیش از یک راه‌حل برای یک مشکل وجود داشته باشد. به جای اصرار بر دیدگاه‌های خود، گوش دهید و گزینه‌های دیگر را ارزیابی کنید. ممکن است آنها جنبه‌ای را مطرح کنند که قبلاً نادیده گرفته‌اید. اصل پل سافو از “نظرات قوی به آرامی نگه داشته شده” به ما می‌گوید قاطعانه از نظرات خود دفاع کنیم اما هر بار که شواهد جدیدی داریم که آنها را نقض می‌کند، آنها را بررسی کنیم (https://bit.ly/softskills-strongop). این یک روش علمی مبتنی بر شواهد است که فردی که ایده یا نظری را ارائه داده است را در نظر نمی‌گیرد.

نگهداری سابقه

یک ایمیل دوستانه پس از یک جلسه غیررسمی به تأیید مجدد نکات کلیدی یا تعهدات انجام شده در طول بحث کمک می‌کند.

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

حسن نیت

بدانید چه زمانی سکوت کنید و پویایی موجود را مشاهده کنید.

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

ارشدیت

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

ارشدیت و تفکر استراتژیک

در شرایط عدم قطعیت، از گرفتن تصمیم یا اقدام، ناموفق نباشید.

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

رهبران کسانی هستند که افق‌های خود را گسترش داده‌اند تا به طور استراتژیک فکر کنند و نقشه راه را برای دیگران ترسیم کنند.

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

هدایت با نمونه

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

رهبران مهندسی توانمند می‌کنند. همانطور که ارشدتر می‌شوید، کمک می‌کند که اسباب‌بازی‌هایتان را رها کنید، مربیگری کنید، واگذار کنید و تیم خود را قادر به موفقیت کنید. این چگونگی مقیاس‌پذیری اثربخشی شماست. این می‌تواند با پرسیدن سؤالات خوب بیشتر از (فقط) ارائه پاسخ‌ها انجام شود.

شما با نمونه هدایت می‌کنید وقتی مشکلات چالش‌برانگیز را ارزیابی می‌کنید و سؤالات مرتبط می‌پرسید وقتی کسی راه‌حلی ارائه می‌دهد.

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

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

مقیاس‌پذیری اثربخشی خود

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

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

وقتی به عنوان یک مشارکت‌کننده فردی شروع می‌کنید، ممکن است یک “تیم” اختصاصی نداشته باشید که رهبری کنید، اما می‌توانید افراد هم فکر را پیدا کنید تا با آنها همکاری کنید (شاید همسو با اهداف شما) و با هم کار کنید تا بسیار بیشتر از آنچه به تنهایی می‌توانستید انجام دهید. با ارشدتر شدن، این تفکر را به سمت ایجاد تیم‌ها و رشد مداوم اثربخشی خود تکامل می‌دهید.

سندرم متقلب

پذیرش اینکه اشتباه کردن، ندانستن پاسخ‌ها، یا جستجوی راهنمایی اشکالی ندارد می‌تواند به غلبه بر سندرم متقلب کمک کند.

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

تیم‌های موثر

ایجاد اعتماد

اعتماد می‌تواند اعضای تیم را برای کار به سمت یک هدف مشترک متحد کند در حالی که بوروکراسی آنها را تقسیم خواهد کرد.

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

ایجاد اعتماد مهمترین جزء تیم‌سازی است. اعتماد بین اعضای تیم در سراسر سلسله مراتب برای انجام سریع کارها و موثر بودن تیم‌ها ضروری است. اعضای تیم ممکن است از فرآیندهای مهندسی نرم‌افزار مختلفی مانند بررسی‌ها و آزمایش‌ها برای بررسی سلامت پروژه استفاده کنند. با این حال، این فرآیندها بدون اعتماد خسته‌کننده و بوروکراتیک می‌شوند. به عنوان مثال، احتمالاً اگر به یک مهندس با برخی کدها اعتماد دارید، در بررسی کد کمتر ایرادگیری خواهید کرد.

درک مدل کسب و کار

تأثیر تجاری تغییر را درک کنید.

هنگامی که مجموعه جدیدی از نیازمندی‌ها را دریافت می‌کنید، انگیزه پشت آنها را درک کنید. بخش “هدف” یا “اهداف تجاری” اسناد نیازمندی‌ها را سرسری نگیرید. برای درک مدل کسب و کار و ارتباط آن با این نیازمندی‌ها، سؤال بپرسید. یک کدبیس موجود یا صحبت با متخصصان موضوعی (SMEs) می‌تواند بینش‌هایی درباره دامنه و معماری ارائه دهد. به مستندات مراجعه کنید یا ویژگی‌ها و موارد استفاده را به فرآیندهای سیستم و جریان‌های داده نگاشت کنید.

“بسیاری از مهندسان نرم‌افزار دوست دارند مشکلات را با یک چالش فنی حل کنند. درک جنبه کسب و کار چیزها و توانایی ارائه راه‌حل‌های مقرون به صرفه می‌تواند پاداش بیشتری داشته باشد. به یاد داشته باشید که کاربران/مشتریان شما نیز افرادی هستند که سعی می‌کنند کار خود را انجام دهند و روز یا هفته را پشت سر بگذارند، درست مانند شما. سعی نکنید زندگی آنها را سخت‌تر از آنچه هست، کنید.” (https://bit.ly/softskills-tc)

افزایش تأثیر خود

درک و زیرکی درباره معادله کسب و کار-نرم‌افزار، تأثیر کار شما را افزایش می‌دهد.

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

مربی‌گری

مربی‌گری دیگران

یک حفاظ باشید با ارائه اطلاعات به موقع تا متربیان شما به مکانی کاملاً نادرست نرسند بلکه به جای آن با انجام کارها خودشان تسلط کسب کنند.

ممکن است خود را در نقش مربی یا متربی در زمان‌های مختلف در دوران حرفه‌ای خود بیابید. مربی‌گری نباید لزوماً یک فرآیند رسمی باشد. می‌توانید به دنبال فرصت‌هایی برای مربی‌گری دیگران باشید یا اجازه دهید حتی به صورت غیررسمی مربی‌گری شوید. مربی‌گری دیگران به شما فرصتی می‌دهد تا خودتان مهارت‌های مردمی را یاد بگیرید. نکات کلیدی زیر را هنگام مربی‌گری به یاد داشته باشید.

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

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

مربی‌گری سازمانی

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

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

نقش متربی

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

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

شما در طول حرفه خود با مربیان، مشاوران یا همکارانی که به آنها نگاه می‌کنید، روبرو خواهید شد.

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

زمان و تعادل کار/زندگی

اگر شما کسی هستید که بر مهارت‌های فنی، عوامل انسانی و دانش حوزه‌ای تسلط پیدا کرده‌اید، مهارت‌های شما به عنوان یک مهندس نرم‌افزار ناگزیر مورد تقاضا خواهد بود. افراد در تیم و سازمان شما با شما مشورت خواهند کرد. علاوه بر تعهدات مهندسی خود، قربانی اضافه‌بار همکاری خواهید شد (https://bit.ly/softskills-overhead). درخواست‌های اقتضایی می‌توانند وقت شما را بگیرند و شما را از انجام آنچه به آن علاقه دارید باز دارند.

مدیریت زمان

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

زمان را در تقویم خود برای کار عمیق متمرکز مسدود کنید. من سال‌هاست که این کار را انجام می‌دهم و آن را برای نوشتن اسناد طراحی یا استراتژی یا فقط کار روی یک مشکل فنی دشوار بسیار موثر یافته‌ام. کار عمیق، کار بدون حواس‌پرتی و با تمرکز بالا است که در زمان کم ارزش زیادی ایجاد می‌کند. کتاب «کار عمیق» کال نیوپورت این موضوع را به خوبی پوشش می‌دهد.

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

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

همچنین دریافته‌ام که تغییر مکان گاهی اوقات می‌تواند به کار عمیق کمک کند. ما گاهی می‌توانیم در دام ارتباط یک مکان خاص (مانند یک میز، اتاق یا ساختمان) با نوع خاصی از کار گیر کنیم و افزودن کمی تنوع می‌تواند به ما کمک کند تا جان تازه‌ای بگیریم.

از خرد کردن ساعات کاری خود اجتناب کنید

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

کار بیش از حد بخشی از یک اخلاق کاری خوب نیست.

شما هرگز نمی‌توانید سخت‌تر از همه افراد در جهان کار کنید. بسیاری از شرکت‌ها کارمندان بیش از حد کار کرده را به عنوان “استاندارد” معرفی می‌کنند و به اشتباه نتیجه می‌گیرند که این همان داشتن یک اخلاق کاری خوب است. موفقیت از عوامل بسیاری می‌آید و نه فقط کار بیش از حد.

تلاش مداوم برای غلبه بر استانداردهای خود غیرواقعی است.

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

زمان محدود است. به جای تلاش برای یافتن زمان بیشتر، کارهای غیرضروری را حذف کنید.

بسیاری از راهنمایی‌ها در مورد ترتیب بهتر کارها صحبت می‌کنند. مشکل واقعی تلاش برای انجام بیش از حد از ابتدا است. به طور بی‌رحمانه‌ای کارهایی را که غیرضروری و اتلاف وقت هستند حذف کنید به جای اینکه سعی کنید زمان محدود را مدیریت کنید.

لازم نیست هر چیز آخری را که می‌گذرد بدانید.

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

افکار بیشتر در مورد این موضوع در “لازم نیست در محل کار دیوانه باشد” توسط جیسون فرید وجود دارد (https://amzn.to/3yqwf1K).

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

مدیریت زمان و حفظ تعادل خوب کار/زندگی برای مهندسان در تمام سطوح حیاتی است. کار اضافه منظم می‌تواند منجر به فرسودگی و استرس شود. استرس می‌تواند باعث سایر عوارض جسمی و روانی شود (https://bit.ly/softskills-complications). ممکن است وسوسه شوید که قبل از اینکه روز خود را به پایان برسانید، مشکلی را حل کنید، اما می‌تواند با گذشت زمان به یک عادت تبدیل شود.

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

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

تخمین‌ها را همزمان با بهبود درک شما از مشکلات به‌روز کنید

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

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

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

تقریباً همیشه می‌خواهید تخمین‌ها برنامه‌زمانی شما را هدایت کنند در مقابل اینکه برنامه‌زمانی تخمین‌ها را هدایت کند. در تیم‌های من، در حالی که گاهی اوقات مهلت‌های غیرقابل تغییر داریم (مثلاً یک کنفرانس)، اگر تخمین‌ها از این تاریخ‌ها فراتر روند، (اغلب) مشکلی نیست - تغییر پیام‌رسانی (مثلاً “پیش‌نمایش”)، قالب‌بندی (“به زودی”) یا انتقال به آینده همیشه گزینه‌هایی هستند که می‌توانیم با رهبری در مورد آنها صحبت کنیم. البته تصدیق می‌کنم که این همیشه بی‌اهمیت نیست. وقتی برنامه‌ها سعی می‌کنند کشیده شوند، می‌توانید کار را به باید-داشته‌ها در مقابل خوب-است-داشته‌ها تقسیم کنید (و اینها را به اسپرینت آینده منتقل کنید) سپس بررسی کنید آیا باید-داشته‌ها مهلت شما را برآورده می‌کنند.

اگر برنامه‌ها هنوز خیلی فشرده هستند، سؤالات دیگری هستند که می‌توانید بپرسید، مانند “آیا می‌توانیم مهندسان بیشتری به این پروژه اضافه کنیم؟” و “آیا کاهش بزرگی در دامنه وجود دارد که هنوز ارسال به موقع را جذاب کند؟”.

لغو پروژه‌ها گاهی اوقات تصمیم درستی (اگرچه ناراحت‌کننده) است.

از این متنفرم، اما لغو یک پروژه گاهی اوقات می‌تواند سالم‌ترین تصمیم بلندمدت برای تیم و سازمان شما باشد. این به خصوص زمانی صادق است که قبل از اینکه فرصتی برای راه‌اندازی، کسب کشش و سپس در نهایت مجبور به منسوخ شدن شود زیرا تأمین نیرو در آن دیگر نمی‌تواند حفظ شود، لغو شود. در صورتی که افراد در مورد آن کنجکاو هستند، بله، من Killed By Google را می‌خوانم (https://bit.ly/softskills-kbg). هدف این است که شرایط منجر به لغو پروژه‌ها را تا حد امکان به حداقل برسانید. من اخیراً یک پروژه چند ساله را لغو کردم و سخت بود.

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

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

در مورد بدهی فنی: یک اونس پیشگیری ارزش یک پوند درمان را دارد

تایتوس وینترز بدهی فنی را به عنوان “تفاوت بین کد و سیستم‌هایی که امروز داریم در مقابل آنچه آرزو می‌کنیم داشته باشیم” تعریف می‌کند، با برخی انواع بدهی که تأثیر بیشتری نسبت به دیگران دارند. برخی بدهی‌ها می‌توانند به دلیل اشتباهاتی باشند که زود تشخیص داده نشده‌اند (نظارت)، برخی دیگر به دلیل آنچه پس از واقعه آموخته شده است (دید در گذشته) و برخی به دلیل تغییر چشم‌انداز سیستم‌های فنی (زمینه).

من دریافته‌ام که اولویت‌بندی مداوم برای مقابله با بدهی فنی گاهی اوقات سخت است زیرا نمی‌توانید همیشه باگ‌هایی را که بروز نکرده‌اند یا قطعی‌هایی که به دلیل “کاهش کافی بدهی” رخ نداده‌اند، کمّی کنید. حفظ علاقه تیم به این نوع کار و پاداش دادن به آن در طول بررسی‌های عملکرد نیز بسیار مهم است. با این حال، هزینه “درمان” می‌تواند بسیار بالاتر باشد زمانی که مشکلات واقعاً شروع به انباشته شدن در طول زمان می‌کنند. مشابه آلودگی، در طول چندین سال، پیشگیری از بدهی فنی استراتژی ارزان‌تری نسبت به کاهش در یک نقطه بعدی است.

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

بدون استراحت و تعادل خوب کار/زندگی، شما یا تیم شما دچار فرسودگی می‌شوید.

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

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

من حدود ۵ سال پیش دچار فرسودگی شدم، اما خوشحالم که بگویم آن را برگرداندم. چه چیزی منجر به آن شد؟ یک بهمن از چیزها بود. من سال‌ها کار را در اولویت قرار داده بودم، ساعات طولانی‌تر و طولانی‌تر کار می‌کردم و به اندازه کافی “نه” نمی‌گفتم. هرگز به اندازه کافی استراحت یا تعطیلات نمی‌گرفتم. من به طور متوسط ۵ ساعت در شب می‌خوابیدم. وقتی خانه بودم، آنقدر کم انرژی بودم که برای خانواده‌ام “حضور” نداشتم، نه به اندازه‌ای که باید. “راه‌حل” انجام کارهای برعکس بود: استراحت کردن، خواب بیشتر، بیشترین ارزش را از ساعاتی که کار می‌کنم فشرده کردن، واگذاری بهتر و داشتن یک “زمان توقف” واضح برای کار.

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

اجرا در سازمان‌های بزرگ می‌تواند کند به نظر برسد. راه‌هایی برای رفع این مشکل وجود دارد.

من بسیاری از گفتگوها با مهندسان داشته‌ام که به این خلاصه می‌شوند: “چرا ارسال X ماهواره در (سازمان بزرگ) اینقدر سخت است؟”. آنالوژی عالی توسط الکس کوموروسک وجود دارد که سازمان‌های بزرگ را با کپک‌های لعابی مقایسه می‌کند (https://bit.ly/softskills-slmo). یعنی، اجرای حتی چیزهای ساده می‌تواند به دلیل سرباد هماهنگی، بسیار کندتر از آنچه انتظار دارید احساس شود. سازمان‌ها سیستم‌ها، ساختارها و پویایی‌های پیچیده‌ای دارند و سرباد افزایش می‌یابد زمانی که تعداد افرادی که باید در یک پروژه هماهنگ شوند، افزایش می‌یابد.

نیروهای بسیاری در اینجا در حال بازی هستند، از جمله کم‌برآورد کردن دشواری کارهای دیگران (مثلاً اگر در حال ساخت یک وابستگی هستند). شما نمی‌توانید این مشکلات را نادیده بگیرید زیرا می‌تواند باعث گسترش اختلال شود. یک راه برای کار از میان چنین سربادهایی این است که چیزها را تا حد امکان از هم جدا کنید تا بتوانند در یک جدول زمانی مناسب فرود بیایند و در نهایت به سمت ارسال X همگرا شوند.

به جای پرداختن به همه X از ابتدا، می‌توانید از تمرکز تنها بر ماهواره (تلاش‌های پرخطر) اجتناب کنید و در عوض ضربه‌های روی سقف (گام‌های ایمن برای آزاد کردن ارزش) را تعریف کنید که شما را به اهداف خود نزدیک‌تر می‌کند. من قویاً توصیه می‌کنم اگر این مشکل آشنا به نظر می‌رسد، بخوانید.

تمرکز بر مشکلات در مقابل پروژه‌ها

بیایید تصور کنیم کاربران شما یک نیاز حل نشده دارند (مثلاً یک مشکل). وقتی شما یک مهندس متصل به یک پروژه خاص هستید، طبیعی است که بپرسید چگونه پروژه خاص شما قرار است این مشکل را حل کند (یک ماکزیمم محلی). در یک سازمان بزرگ با پروژه‌هایی با شکل‌های مشابه، بسیار ممکن است که چندین مهندس را ببینید که سعی می‌کنند به طور مستقل به این روش فکر کنند (“چگونه پروژه من این مشکل را حل می‌کند؟”).

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

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

نتیجه‌گیری

“خود را با برتری احاطه کنید و با افرادی کار کنید که در کار خود بهترین هستند” - برایان استافنبیل

در روابط و دوستی با افرادی که می‌توانید از آنها یاد بگیرید، سرمایه‌گذاری کنید. نسبت به راهنمایی، مربیگری، موفقیت‌ها و شکست‌های آنها باز باشید. هرگز از درخواست کمک یا بینش نترسید. در بسیاری از موارد، فقط یک سؤال فاصله دارید.

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