تیم لیستر - یکی از نویسندگان کتاب

• "عامل انسانی. پروژه ها و تیم های موفق" (کتاب اصلی "Peopleware" نام دارد)
• "Waltzing with the Bears: مدیریت ریسک در پروژه های نرم افزاری"
• «آدرنالین دیوانه شده و توسط الگوها زامبی شده است. الگوهای رفتاری تیم های پروژه

همه این کتاب‌ها در زمینه خود کلاسیک هستند و با همکاری همکارانشان در ایران نوشته شده‌اند انجمن سیستم های آتلانتیک. در روسیه، همکاران او مشهورترین هستند - تام دیمارکو и پیتر هروشکا، که آثار معروف بسیاری نیز نوشت.

تیم 40 سال تجربه در توسعه نرم افزار دارد؛ در سال 1975 (هیچ یک از کسانی که این هابراپست را نوشتند در این سال متولد نشدند)، تیم قبلاً معاون اجرایی Yourdon Inc بود. او اکنون وقت خود را صرف مشاوره، تدریس و نوشتن می کند و هر از گاهی به آن سر می زند با گزارشات کنفرانس های سراسر جهان

ما با تیم لیستر به خصوص برای هابر مصاحبه ای انجام دادیم. او کنفرانس DevOops 2019 را افتتاح خواهد کرد، و ما سؤالات زیادی درباره کتاب و موارد دیگر داریم. این مصاحبه توسط میخائیل دروژینین و اولگ چیروخین از کمیته برنامه کنفرانس انجام می شود.

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

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

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

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

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

مایکل: یعنی شما پروژه ها را راه اندازی می کنید، نوعی شروع کار انجام می دهید و بررسی می کنید که ریل ها در مسیر درست قرار دارند؟

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

19 سال چابک

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

تیم: من فکر می کنم که روش های چابک، با شروع مانیفست چابک در سال 2001، چشمان صنعت را باز کرد. اما از سوی دیگر، هیچ چیز کامل نیست. من همه طرفدار توسعه تکراری هستم. تکرار در اکثر پروژه ها بسیار معنادار است. اما سوالی که باید در مورد آن فکر کنید این است: زمانی که محصول خارج شد و مورد استفاده قرار گرفت، چقدر دوام می آورد؟ آیا این محصولی است که قبل از جایگزینی با چیز دیگری شش ماه دوام می آورد؟ یا این محصولی است که برای سالهای بسیار زیاد کار خواهد کرد؟ البته نام نمی برم، اما... در نیویورک و جامعه مالی آن، بنیادی ترین سیستم ها بسیار قدیمی هستند. این شگفت انگیز است. به آن‌ها نگاه می‌کنید و فکر می‌کنید، اگر فقط می‌توانستید به سال 1994 برگردید و به توسعه‌دهندگان بگویید: «من از آینده آمده‌ام، از سال 2019. فقط تا زمانی که نیاز دارید این سیستم را توسعه دهید. آن را قابل گسترش کنید، به معماری فکر کنید. سپس برای بیش از بیست و پنج سال بهبود خواهد یافت. اگر توسعه را کمی بیشتر به تأخیر بیندازید، در طرح بزرگ چیزها هیچ کس متوجه نمی شود!» وقتی در بلندمدت چیزها را تخمین می زنید، باید در نظر بگیرید که در مجموع چقدر هزینه خواهد داشت. گاهی اوقات معماری خوب طراحی شده واقعا ارزشش را دارد و گاهی اوقات اینطور نیست. باید به اطراف نگاه کنیم و از خود بپرسیم: آیا برای چنین تصمیمی در موقعیت مناسبی هستیم؟

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

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

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

اولگ: شما به مانیفست چابک اشاره کردید. آیا باید به نحوی آن را با در نظر گرفتن درک مدرن از موضوع به روز کنیم یا تجدید نظر کنیم؟

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

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

Peopleware: 30 سال بعد

اولگ: آیا Peopleware یک انقلاب و همچنین مانیفست بود؟

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

علیرغم این واقعیت که تیم تعداد زیادی گفتگو انجام داده است، تعداد بسیار کمی از آنها در یوتیوب پست شده است. می توانید به گزارش «بازگشت نرم افزارهای مردمی» از سال 2007 نگاه کنید. کیفیت، البته، چیزهای زیادی برای دلخواه باقی می گذارد.

مایکل: آیا در 30 سال گذشته از زمان انتشار کتاب، چیزی تغییر کرده است؟

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

همه ما در DevOps زندگی می کنیم

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

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

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

مایکل: کل ایده devops ارائه تحولات معنادار در اسرع وقت است. من می بینم که سرعت جهان بیشتر و بیشتر شده است. چگونه با چنین شتاب هایی سازگار شویم؟ ده سال پیش این وجود نداشت!

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

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

الگوها و ضد الگوها

اولگ: شما معمولاً در مورد الگوها و ضد الگوها صحبت می کنید و این تفاوت بین زندگی و مرگ پروژه ها است. و اکنون، deops به زندگی ما نفوذ می کند. آیا الگوها و ضدالگوهای خاص خود را دارد که بتواند پروژه را درجا بکشد؟

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

تازه داشتیم با رفقا بحث می‌کردیم که امسال یک سالگرد است، پنجاه سالی که آدم‌ها روی ماه فرود آمده‌اند. این در سال 1969 بود. فناوری که به مردم کمک کرد تا به آنجا برسند، حتی فناوری 1969 نیست، بلکه مربوط به سال 1960 یا 62 است، زیرا ناسا می خواست فقط از چیزهایی استفاده کند که شواهد خوبی از قابلیت اطمینان دارند. و بنابراین شما به آن نگاه می کنید و می فهمید - بله، و آنها درست بودند! در حال حاضر، نه، نه، اما شما به دلیل اینکه همه چیز بیش از حد تحت فشار قرار می گیرد و از همه جا فروخته می شود، با فناوری دچار مشکل می شوید. مردم از همه جا فریاد می زنند: "ببین، چه چیزی، این جدیدترین چیز، زیباترین چیز در جهان است، برای همه مناسب است!" خب، همین... معمولاً همه اینها فقط یک طعمه است، و بعد باید همه را دور انداخت. شاید همه اینها به این دلیل است که من قبلاً یک پیرمرد هستم و با شک و تردید به چنین چیزهایی نگاه می کنم، وقتی مردم تمام می شوند و می گویند که تنها و صحیح ترین راه را برای ایجاد بهترین فناوری ها پیدا کرده اند. در این لحظه صدایی از درونم بلند می شود که می گوید: "چه بهم ریخته!"

مایکل: در واقع، چند بار در مورد گلوله نقره بعدی شنیده ایم؟

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

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

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

"مهندس دووپس" اسطوره ای

اولگ: حالا همه در حال پیاده سازی devops هستند. شخصی در مورد devops در اینترنت می خواند و فردا جای خالی دیگری در یک سایت استخدام ظاهر می شود. "مهندس دووپس". در اینجا می خواهم توجه شما را جلب کنم: آیا فکر می کنید این اصطلاح "مهندس توسعه" حق زندگی دارد؟ این عقیده وجود دارد که devops یک فرهنگ است و چیزی در اینجا جمع نمی شود.

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

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

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

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

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

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

"متخصصان همه چیز"

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

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

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

خطرات و عدم اطمینان

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

اولگ: سریع حرکت کنید و چیزها را بشکنید!

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

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

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

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

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

باز هم، چه چیزی پروژه شما را منحصر به فرد می کند؟ بیایید ببینیم چه چیزی می تواند پروژه ما را از ریل خارج کند. چه کنیم تا احتمال این اتفاق را به حداقل برسانیم؟ معمولاً نمی‌توان آنها را 100٪ خنثی کرد و با وجدان راحت گفت: "همین است، این دیگر مشکلی نیست، خطر حل شده است!" برای من این نشانه رفتار بزرگسالان است. این تفاوت بین یک کودک و یک بزرگسال است - کودکان فکر می کنند که جاودانه هستند، هیچ چیز نمی تواند اشتباه باشد، همه چیز خوب خواهد شد! در همان زمان، بزرگسالان تماشا می کنند که چگونه کودکان سه ساله در زمین بازی می پرند، حرکات را با چشمان خود دنبال می کنند و با خود می گویند: "اوه اوه اوه اوه." من در نزدیکی می ایستم و آماده می شوم که وقتی کودک سقوط کرد، بگیرم.

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

تفکر مهندسی بزرگسالان

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

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

اولگ: به طور نسبی، اگر طبق کانبان کار می کنید، وقتی به گلوگاه برخی از تست ها برخورد کردید، می توانید کاری را که در آنجا انجام می دادید (مثلاً برنامه نویسی) رها کنید و به آزمایش کنندگان کمک کنید.

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

اولگ: زندگی شما پروژه شماست که مدیریت می کنید.

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

چگونه وارد مدیریت ریسک شویم

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

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

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

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

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

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

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

قیمت ارتباطات

اولگ: آیا استخدام چنین کارکنان خروجی به دلایل مختلف گرانتر نیست؟ بالاخره به جای کار مدام در حال چت کردن هستند!

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

مایکل: این امر برای همه افراد درگیر در پروژه، صرف نظر از تخصص، مهارت یا روش کار، صدق می کند. همه شما علاقه مند به موفقیت پروژه هستید.

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

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

تیم: مدیران؟ هوم اغلب، مدیران تحت فشار مشکلات هستند، با نیاز به رهاسازی فوری چیزی و انجام تحویل و مواردی از این دست مواجه می شوند. آنها تماشا می کنند که چگونه ما دائماً در مورد چیزی بحث می کنیم و بحث می کنیم و آن را اینگونه می بینند: گفتگوها، گفتگوها، گفتگوها... چه گفتگوهای دیگری؟ بازگشت به کار! چون حرف زدن برایشان حس کار نیست. شما کد نمی نویسید، نرم افزار را آزمایش نمی کنید، به نظر نمی رسد کاری انجام دهید - چرا شما را برای انجام کاری نمی فرستید؟ پس از همه، تحویل در حال حاضر در یک ماه!

مایکل: برو یه کد بنویس

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

اولگ: میشا، تو به چیزی فکر می کنی.

مایکل: ببخشید در فکر فرو رفتم و فلاش بک گرفتم. همه اینها من را به یاد یک تجمع جالب افتاد که دیروز رخ داد ... تجمعات دیروز خیلی زیاد بود ... و همه چیز بسیار آشنا به نظر می رسد!

زندگی بدون حقوق

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

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

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

بهترین توصیه

مایکل: برای بازگشت به "بهترین توصیه"، آیا چیزی وجود دارد که بارها و بارها به مشتریان خود بگویید؟ ایده ای در مورد 80/20 وجود دارد و برخی توصیه ها احتمالاً بیشتر تکرار می شوند.

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

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

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

مدیریت ریسک را تمرین کنید!

مایکل: به نظر شما چند سازمان درگیر مدیریت ریسک هستند؟

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

مایکل: و با این حال، چه تعداد از این شرکت ها، پنج درصد، در مدیریت ریسک مشارکت دارند؟

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

بله، من اغلب می شنوم، "ما مشکلات را به محض ایجاد آنها حل خواهیم کرد." حتماً این کار را خواهیم کرد؟ آیا واقعا تصمیم خواهیم گرفت؟

اولگ: می‌توانید ساده‌لوحانه این کار را انجام دهید و به سادگی تغییرات مهم را در منشور پروژه بنویسید، و اگر ثابت‌ها شکستند، پروژه را مجدداً راه‌اندازی کنید. به نظر می رسد بسیار بد است.

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

تیم: بیایید دکمه تنظیم مجدد را فشار دهیم! نه اینطوری کار نمیکنه

سخنرانی اصلی در DevOops 2019

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

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

مایکل: من هم سال هاست که در زمینه مشاوره کار می کنم و به خوبی می فهمم که در مورد چه چیزی صحبت می کنید.

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

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

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

تیم لیستر با یک سخنرانی کلیدی وارد خواهد شد "شخصیت ها، جامعه و فرهنگ: عوامل مهم برای شکوفایی"به کنفرانس DevOops 2019 که در تاریخ 29 تا 30 اکتبر 2019 در سن پترزبورگ برگزار خواهد شد. می توانید بلیط تهیه کنید در وب سایت رسمی. ما در DevOops منتظر شما هستیم!

منبع: www.habr.com