введение

Возвращаясь к 8 годам назад, моя первая стажировка в моей жизни была в качестве инженера C++ в отделе беспроводного поиска интернет-компании. В то время я был в приподнятом настроении и хотел сделать большую работу, в результате я написал первый в своей жизни Casestudy, когда впервые вышел в интернет. Из-за непонимания среды развертывания файл конфигурации в библиотеке SVN был отправлен в онлайн по ошибке, и после выхода в интернет я пошел обедать.Когда я вернулся с обеда, я обнаружил, что мастер был спешу откатить конфигурацию. В результате этого сбоя основная служба была недоступна в течение 20 минут, что затронуло миллионы пользователей. Это только начало, за следующие полгода я совершил почти все ошибки, которые могут совершать новички на рабочем месте. Архитектор попросил меня изучить план повышения производительности обхода, две недели я упорно работал, так и не придя к каким-либо выводам, план развития, который был изначально составлен, потому что мне нужно было временно вернуться, чтобы написать диссертацию, застал менеджера врасплох; Я участвовал в проекте симпозиума, "играя в соевый соус" во всем процессе... В то время я тоже был очень огорчен. Я уходил почти каждую ночь после 11 часов. Я был очень уставшим и очень тяжелым, но я все еще не мог получить желаемые результаты.

Спустя 8 лет я постепенно вырос из новичка на рабочем месте в технического лидера. Я обнаружил, что многие студенты в команде продолжали повторять те же ошибки, что и в прошлом. Дело не в том, что они плохо работали, что пошло не так? Посмотрев и подумав некоторое время, я думаю, что нашел ответ. То есть: большинству наших одноклассников не хватает принципиальности в работе. Принципы подобны «маякам», которые направляют наши действия, связывая наши ценности и действия. Не так давно идея, изложенная Рэем Далио, основателем фонда Бриджуотер, в книге «Принципы», взорвала круг друзей.У каждого должны быть свои принципы, и когда нам нужно сделать выбор, мы должны придерживаться принципов как центра.. Но в реальной жизни нам часто не хватает краткого изложения принципов.Для многих людей это метафизика, которую можно только понять и не описать словами.Это тайна, принадлежащая старым водителям, но это не так.

«Стремление к совершенству» — это ценности Meituan. Как техник, как мы должны это практиковать? В этой статье изложены десять принципов улучшения, которые надеются вдохновить вас и лучше направить наши действия.

Принцип 1: Осведомленность владельца

«Собственническое сознание» в основном отражается на двух уровнях: один — серьезное и ответственное отношение, а другой — активный настрой.

Добросовестность и ответственность - главное в работе. Во-первых, возьмите на себя ответственность за результаты, которые мы обеспечиваем. Каждый дизайн-документ и каждую строчку кода в проекте нужно прорабатывать тщательно и нести ответственность за его качество. Если логика дизайн-документа хаотична, код не прокомментирован, а при тестировании обнаружена куча багов, то это не только повлияет на качество сдачи проекта RD, но и плохо скажется на RD, QA, ПМ и т.д., которые работают вместе. Со временем общее качество доставки и эффективность работы команды будут постепенно снижаться и даже приводить к возникновению чувства недоверия среди членов команды. Во-вторых, мы несем ответственность за разработанную систему. Нужно ли улучшать архитектуру системы, полны ли интерфейсные документы, полны ли журналы, нужно ли расширять базу данных, достаточно ли места в кэше и т. д. — все это необходимо реализовать. Как владелец системы, пожалуйста, будьте внимательны.

Проактивность является требованием более высокого уровня для «Осведомленности владельца».. RD ежедневно сталкивается с большим количеством работы, и многие из них не запланированы, что требует инициативы. Например, каждый день мы можем сталкиваться с большим количеством технических запросов, и если вопросы, поднятые клиентами, не будут отвечать в течение длительного времени, это приведет к плохому опыту работы с клиентами. Многие студенты говорили, что были заняты своей работой и не имели времени заниматься ею, некоторые студенты считали этот вопрос не очень важным, а многие студенты видели его, но не знали, как на него ответить. просто притворились, что не видят его, когда увидели. Все это проявления отсутствия осознания Владельца. Правильный способ - активно продвигать решение проблемы.Если время не может быть выделено или вы не знаете, как ее решить, вы можете напрямую сообщить о проблеме одноклассникам, которые могут ее решить. Проактивность также может проявляться по-разному. Например, многие студенты спонтанно выясняют текущее состояние ответственных служб, выдвигают предложения по улучшению в соответствии с проблемами, выявленными интерфейсом с точки зрения производительности, и продолжают продвигать решения; есть также студенты, которые берут на себя инициативу роль главного R в межкомандном общении, а также активно выявлять и выявлять проблемы.Содействовать прогрессу совместной команды и обеспечивать плавный ход проекта. Все эти ученики составляют костяк команды. Поэтому, пока мы хорошо делаем свою работу, мы также должны взять на себя инициативу посвятить себя «внешней» работе. Как бы усердно вы ни работали, вы будете пожинать плоды, не устанавливайте для себя ограничений и стремитесь стать лучше.

Принцип 2: Концепция времени

Я считаю, что чувство времени есть у всех, но их может быть не так много, что реально можно реализовать на месте. Интернет — быстро развивающаяся отрасль, и эффективность исследований и разработок RD — важное проявление жесткой силы компании. Своевременная сдача проекта — очень важная способность к исполнению, от которой во многом зависит, как руководители и коллеги оценивают свою надежность. Вы можете спросить: почему для проектов почти одинаковой сложности одни ученики часто запаздывают, а другие каждый раз могут начать вовремя? Очень важная причина заключается в том, что эти студенты, которые успевают вовремя, часто обладают следующими двумя характеристиками:Есть план выполнения дел, и работа расставлена ​​по приоритетам.

Организация работы должна быть запланирована. Обычно RD может оценить точное время разработки после проверки проекта, а затем разумно организовать разработку, совместную отладку и план тестирования. Если это руководитель проекта, он будет включать в себя координацию студентов из нескольких типов работы, таких как FE, QA и PM, для совместного выполнения работы. Предупрежден — значит вооружен, не предугадывая потери. В процессе планирования постарайтесь максимально разбить каждый элемент (по крайней мере, до степени детализации pd). Получается, что чем мельче гранулярность, тем точнее план и тем меньше погрешность между реальным временем разработки и планом. Кроме того, обязательно определите четкие проверяемые результаты и установите некоторые ключевые моменты в плане проверки. Многочисленные кровавые факты говорят нам о том, что многие задержки проектов вызваны разногласиями между двумя сторонами по некоторым ключевым пунктам поставки. Например, интерфейсный документ внутреннего RD планируется предоставить в пятницу, FE полагает, что это утро пятницы, а RD полагает, что он должен быть представлен перед выходом с работы в пятницу, что приведет к ошибке 1pd в расписании. Поэтому нам нужно сделать план достаточно детализированным и проверить ключевые моменты времени.

Расставьте приоритеты в организации работы. Каждый день мы сталкиваемся со многими вещами, и мы должны научиться различать приоритетность этих задач. Вы можете попробовать использовать «Закон Эйзенхауэра» (правило четырех квадрантов), который делит работу на четыре квадранта в соответствии с важностью и срочностью. Расставьте приоритеты важных и срочных дел; важные и несрочные дела можно отложить, но их следует продолжать; срочные и неважные дела можно делегировать наиболее подходящему человеку по мере необходимости; неважные и несрочные дела можно считается не выполненным. Причина, по которой многие проекты не могут быть сданы вовремя, заключается в том, что исполнители не могут отличить приоритет от приоритета. Например, ЭУ нужно использовать в разработке, некоторые студенты, не знакомые с ЭУ, могут захотеть систематически осваивать эти знания, и они окунутся в океан ЭУ. В конце концов обнаружилось, что работа, которую можно было выполнить за один день, серьезно затянулась. На практике нам следует избегать такого метода работы, как «ставить телегу впереди лошади». В данном случае "систематическое изучение ЭУ" - дело важное, но не срочное. Научитесь определять эти отвлекающие рабочие элементы и следите за тем, чтобы важные и срочные дела выполнялись вовремя.

Принцип 3: Начинайте с конца

«Начинай с конца в уме» — привычка, упомянутая Стивеном Кови в «Семи навыках высокоэффективных людей». Он основан на том принципе, что все вещи создаются дважды (первое творение в уме и второе творение в физическом мире). Интуитивное выражение:Сначала подумайте о своих целях, а затем усердно работайте над их достижением.

На работе многие RD склонны просто ходить с опущенной головой и редко смотреть в небо. При подведении итогов каждого квартала перечисляется множество проектов и в них вкладывается много сил. Однако трудно сказать, какие преимущества принесли эти проекты и какие улучшения были внесены в бизнес. Это показывает, что в работе не соблюдается принцип «начинай с конца». Кроме того, многие студенты не уделяли должного внимания целям и преимуществам в процессе выдвижения требований, а после запуска системы не продолжали следить за результатами использования. Особенно это проявляется в проектах по технической оптимизации. Например, в проекте по оптимизации производительности интерфейса, после усилий RD по оптимизации, системный TP99 был укорочен на 60%, а поддержка QPS увеличена в 2 раза. Но насколько система нуждается в оптимизации? Можно ли сократить его на 60% и увеличить в 2 раза, чтобы удовлетворить спрос? Перед оптимизацией многие студенты часто забывают задать предустановленную цель (насколько меньше TP99 и насколько поддерживается QPS). Мы должны четко понимать, что для оптимизации должна быть причина, например, ожидается резкое увеличение трафика в определенный праздник или слишком высокий коэффициент тайм-аута интерфейса.Если оптимизация не проведена, система может быть под угрозой простоя. Решение конкретных проблем является конечной целью технической оптимизации.Итак, чтобы поставить цель в соответствии с проблемой, оптимизировать.

Принцип «начинай с конца» также применим к нашему обучению. Многие студенты прочитали много технических статей, но всегда чувствуют, что ничего не знают. Очень важная причина заключается в том, что нетучиться с целью. В эту эпоху информационного взрыва, если вы будете получать статьи, распространяемые различными публичными аккаунтами, фрагментарно, эффект будет практически незаметен. Перед изучением мы должны спросить себя, какова цель этого изучения? Хотите ли вы понять принцип постоянства Redis, или понять механизм синхронизации Redis master-slave, или изучить всю систему архитектуры Redis Cluster? Если мы сможем осуществлять сбор релевантных данных и обучение с помощью вопросов и целей, мы получим вдвое больший результат с половиной усилий. Эффект от такого режима обучения намного лучше, чем от фрагментарного чтения.

Принцип 4: Замкнутое мышление

Вы когда-нибудь сталкивались с таким сценарием: Участвовали в обзоре дизайна (или требования), и все с энтузиазмом выдвинули множество разумных мнений.При повторном рассмотрении только для того, чтобы обнаружить, что многие из проблем, поднятых в первый раз, не были улучшены. , Многие из обсуждаемых вопросов необходимо обсуждать с нуля. Эта ситуация является типичной работой незамкнутого цикла.

Я уже читал фразу: Надежен человек или нет, зависит от того, сможет ли он все объяснить, заставить все случиться и на все иметь ответ. В этом заключается важность замкнутого мышления.Это подчеркивает мгновенное закрытие обратной связи, если кто-то поручит нам задачу, обязательно дайте четкий отзыв в отведенное время, вне зависимости от результата выполнения. Например, на межведомственном коммуникационном совещании, несмотря на то, что все стороны пришли к соглашению, инициатор совещания сделал итоговую запись общеизвестной. Тем не менее, этот шаг фактически не завершил реальный замкнутый цикл, и в процессе реализации все еще могут быть некоторые потенциальные проблемы. Например, был ли протокол собрания тщательно проверен и подтвержден всеми сторонами? Каков был четкий прогресс в работе на собрании? Есть ли механизм проверки результата завершения? Если этого не сделать, то попадет в порочный круг «общение-обнаружение проблем-общение-повторное открытие проблем».Настоящий замкнутый цикл требует, чтобы мы выработали привычку думать обо всем на работе, делать выводы в общении, получать обратную связь в уведомлениях и принимать в To Do.

«Замкнутое мышление» также требует способности периодически и проактивно предоставлять периодическую обратную связь.. Когда я только начал работать, я взял проект продолжительностью два месяца. Весь проект нужно завершить в одиночку, и он развивается упорядоченно по плану каждый день. Примерно через две недели Лидер спросил о ходе проекта, хотя я уже сказал ему, что все в порядке. Однако Лидер сказал мне, что из-за того, что я не разговариваю с компьютером каждый день, он был очень сбит с толку. В это время я осознал очень важную проблему, между мной и руководителем существует информационная асимметрия. С тех пор мне приходилось время от времени сообщать ему о прогрессе.Даже если это всего лишь короткое предложение, я ясно чувствую, что его доверие ко мне сильно возросло. Особенно после того, как я стал лидером, мое понимание этой замкнутой обратной связи стало более глубоким. С точки зрения Лидера, он на самом деле просто хочет знать, нормально ли продвигается проект и есть ли проблема, для решения которой требуется его помощь.

Принцип 5: Оставайтесь в благоговении

«Сердце джентльмена всегда в благоговении.» Поддержание в сердце благоговения может помочь нам совершать меньше ошибок. В работе есть различные спецификации, такие как спецификации кода, спецификации дизайна, спецификации ввода в эксплуатацию и так далее. Мы должны понимать, что формулировка этих норм должна основываться на каких-то объективных причинах, и они являются опытом, накопленным бесчисленными Случаями в истории. Каждый член команды должен учиться и неукоснительно следовать, особенно это важно для новичков.

Когда мы вводим новую команду, пожалуйста, временно забудьте предыдущие привычки, узнайте существующие нормы команды как можно скорее, и сделайте себя в соответствии с командой. Взяв в качестве примера стиль кодирования, многие студенты часто привыкают к своему прежнему стилю написания кода, а работая над первым проектом новой компании, они также называют переменные и пакеты в соответствии со своими привычками. В результате в процессе код-ревью было высказано много мнений о ревизии, и нам пришлось переделывать и переписывать, что не стоило потерь. Если вы сможете сохранить чувство благоговения и заранее понять стандарты кодирования, такого рода проблемы можно полностью избежать. Аналогичные проблемы также включают непонимание онлайн-процесса, незнание операций отката, непонимание процесса онлайн-изменения SRE и т. д. Помимо этих очевидных норм, существуют некоторые устоявшиеся правила. Мое личное предложение: если вы в чем-то не уверены, вы можете спросить других коллег, а не делать что-то, основываясь на своих чувствах.

Пребывание в благоговении не означает выход «из коробки». После того, как мы полностью поймем эти нормы и условности, если мы почувствуем, что что-то неуместно, мы можем обсудить со всей группой студентов, следует ли принимать новые предложения, а затем своевременно обновлять и повторять. фактически,Поддержание норм и условностей в актуальном состоянии — еще одна форма благоговения.

Принцип 6: Не более двух вещей

«Ничто не больше, чем две вещи» — принцип, которого всегда придерживалась наша команда, который можно интерпретировать как два смысла.

Смысловой слой - это **"все обзоры и обсуждения проблем, не более двух раз"**. Причина этого требования в том, что мы обнаружили, что многие RD тратят свое время на бесконечные обзоры и обсуждение проблем, и очень мало времени на самом деле тратится на реальную разработку. В реальных сценариях работы мы часто сталкиваемся с некоторыми незрелыми обзорами требований. В этих документах с требованиями либо предыстория и цели неоднозначны, либо описание продуктового решения недостаточно подробное, либо есть неясности. RD и PM были вынуждены проводить повторные обсуждения.Однажды я столкнулся с обзором требований, который пересматривался трижды. Та же проблема часто встречается в обзорах дизайна. Хотя план необходимо неоднократно обсуждать, если консенсус не может быть достигнут в течение длительного времени, это отнимет много драгоценного времени RD и PM, что противоречит концепции повышения эффективности исследований и разработок. Поэтому наша команда оговаривает: **Все обзоры составляются до двух раз. ** Таким образом, заинтересованные стороны вынуждены делать все возможное для разработки требований и решений. Прежде чем организовать совещание по рассмотрению, постарайтесь прийти к соглашению со всем соответствующим персоналом, узнать мнения друг друга и провести целенаправленные обсуждения, которые могут значительно повысить эффективность и качество совещания по рассмотрению. Если вы не пройдете первую проверку, у вас есть только один шанс на проверку. Как только вы дважды потерпите неудачу, вам нужно перейти к Casestudy.

Другое значение принципа «ничего, кроме двух» состоит в том, что «Не повторяйте одну и ту же ошибку дважды". После каждого сбоя Casestudy должен провести глубокий обзорный обзор, провести анализ причин сбоя по принципу "5 Почему" и предоставить четкий и выполнимый список дел. На каждом ежеквартальном итоговом собрании каждый размышляет над проблемой, которая должны быть сделаны в следующем квартале. Мы не должны повторять подобные ошибки. Конфуций сказал: «Нет гнева, нет сожалений.» Только размышляя и развивая ошибки, мы можем стать лучше.

Принцип 7: Дизайн прежде всего

Принцип «сначала дизайн» относительно более конкретен. Причина, по которой он указан отдельно, заключается в том, что архитектурный дизайн слишком важен. Дядя Боб однажды сказал: «Цель архитектуры программного обеспечения — минимизировать человеческие ресурсы, необходимые для создания и обслуживания системы».

Дизайн архитектуры связан не только с качеством системы, но и с эффективностью команды.. Многие команды также четко оговаривают, что проекты с циклом разработки более 3pd должны иметь проектную документацию, а проекты с циклом разработки более 5pd должны иметь обзор проекта. В конкретном процессе реализации по разным причинам дизайн часто не может достичь ожидаемого эффекта. Некоторые из причин заключаются в том, что проектный цикл сжат и уже слишком поздно проектировать с достаточной детализацией; некоторые из них связаны с тем, что RD субъективно считает проект относительно простым, а проектирование делается наспех.Многочисленными фактами доказано, что игнорирование предварительного проекта часто приводит к существенному удлинению последующего цикла разработки, что несет с собой большой риск задержки проекта. И самое страшное, что неправильный дизайн влечет за собой огромные постэксплуатационные затраты на проект, приходится выделять время на оптимизацию и реконструкцию проекта.. Поэтому всегда помните о принципе «дизайн прежде всего». Заточка ножей не порежет дрова случайно, а хороший дизайн на ранней стадии принесет большую пользу при разработке проекта и последующем обслуживании.

Принцип «сначала дизайн» требует написания проектов, понятных другим.. Самый простой способ понять систему — это объединить проектную документацию и код. В реальной работе многие студенческие проектные документы сбивают всех с толку. На самом деле процесс проектирования — это интеллектуальное творение, и мы надеемся, что он может стать воплощением индивидуальной и коллективной мудрости. Как сделать наш дизайн понятным? Я лично считаю, что дизайн должен попытаться использовать более разумную логику для организации некоторых моментов в дизайне. Например, материалы можно организовать с помощью структуры от абстрактного к конкретному и от общего к баллам. В процессе проектирования необходимо взять требования за отправную точку, упростить проблему за счет разумной абстракции, прояснить взаимосвязь между различными модулями, а затем подробно описать детали реализации модулей. После завершения дизайна вы можете отправить его более старшему RD или PM на рассмотрение, а затем улучшить его в соответствии с их отзывами. Хороший дизайн должен быть логически ясным и простым для понимания, с деталями, которые можно реализовать.

Принцип 8: Баланс P/PC

Принцип «баланса P/PC», то есть принцип баланса выпуска и мощностей. Басни Эзопа рассказывают историю о «курице, несущей золотое яйцо». Выход подобен «золотому яйцу», а производительность — «курице, несущей золотые яйца». Люди, которые «тяжелее яиц, чем гуси», могут даже не иметь возможности сохранить свои яйценосные активы;Выход и мощность должны быть сбалансированы для действительно высокой производительности. Чтобы дать вам более четкое представление об этом принципе, в этой статье приведены два примера.

С системной точки зрения каждая система реализует свой результат путем непрерывного наложения функций, а производительность системы характеризуется рядом характеристик, таких как масштабируемость и стабильность системной архитектуры. Для достижения баланса между производительностью и производственными мощностями необходимо постоянно оптимизировать техническую архитектуру в процессе постоянной поддержки потребностей бизнеса. Если слепо соответствовать бизнес-требованиям, через определенный промежуток времени система будет становиться все медленнее и медленнее, что в конечном итоге повлияет на стабильность бизнеса; наоборот, система без каких-либо результатов для бизнеса в конечном итоге умрет.

Глядя на эту проблему с точки зрения RD, RD создает ценность для компании и реализует свою продукцию, предъявляя требования. Производственная мощность RD относится к техническим возможностям, мягким качествам и физическому здоровью, с этими капиталами мы можем осуществлять непрерывный выпуск продукции. В своей повседневной работе я обнаружил, что многие RD склонны сосредотачиваться только на результатах. Они также усердно работают над проектами, но методы, используемые в каждом проекте, по-прежнему следуют их предыдущим последовательным идеям. В конце концов, проект не только работал посредственно, но он еще и жаловался, что не получает никакого роста. Это проявление дисбаланса P/PC.Если вы сможете постоянно улучшать свои технические возможности и социальные качества посредством обучения и обобщения в процессе выполнения проектов, а также применять их при реализации и доставке проектов, я верю, что будет достигнут беспроигрышный результат.

Принцип «баланса P/PC» также применим ко многим другим областям, таким как команды, семьи и т. д., и я также очень уважаю этот принцип. Я надеюсь, что каждый сможет принять это как основной принцип и стремиться найти баланс между производительностью и производственными мощностями.

Принцип 9: Умейте задавать вопросы

«Умей задавать вопросы», прежде всего усердно задавай вопросы. Любопытство проистекает из любопытства, которое является человеческим инстинктом. На работе вы должны выработать хорошую привычку усердно задавать вопросы, задавать вопросы, если вы не понимаете, и не отказываться от возможности задавать вопросы только потому, что вы ленивы или из любви. Когда вы столкнетесь с другой точкой зрения, также вежливо спросите. Теорема Полка говорит нам,Только в дебатах могут родиться лучшие идеи и лучшие решения.

В обзорах дизайна, обзорах кода и других действиях, отражающих коллективный разум, необходимо поднимать проблемы. Я часто вижу, что многие студенты не говорят ни слова в течение всего процесса рецензирования, что является пустой тратой времени каждого. Цель обзора проекта — дать возможность каждому выдвинуть предложения по улучшению и прийти к соглашению. Мы призываем всех задавать больше вопросов, выражать свои внутренние сомнения, а затем получать ответы посредством общения.

«Умейте задавать вопросы», но также умейте задавать вопросы. Почему некоторые учащиеся могут задавать хорошие вопросы во время проверки проекта, а другие не могут задавать никаких вопросов? Помимо различий в запасах знаний, профессиональных навыках, опыте и т. д., есть еще один важный момент: критическое мышление.

Критическое мышление ратует за то, что рациональное мышление достигается через критическое мышление, то есть познание и овладение сущностью вещей. Относительно того, как мыслить критически, вы можете обратиться к некоторым классическим книгам, таким как «Критическое мышление», «Учимся задавать вопросы» и так далее. Столкнувшись с решением на работе, перед вами будут различные мнения, поэтому мы должны научиться использовать критическое мышление, чтобы анализировать, является ли аргумент каждого человека надежным, является ли аргумент разумным, есть ли неявная позиция. Аналогично, читая технический блог, также используйте критическое мышление, задайте еще несколько вопросов, почему, разумны ли выводы, сделанные автором? Достаточно ли аргументов? Только таким образом можно непрерывно приобретать настоящее знание.

Принцип 10: менталитет пустой чашки

«Полные потери, скромные выгоды», «менталитет пустой чашки» - последний принцип. Я думаю, что это тоже обязательное условие для того, чтобы человек продолжал расти. У техников обычно высокомерие в костях, и они будут продолжать расти с повышением квалификации и достижениями. Сяобай, который новичок на рабочем месте, может быть очень скромным, но после нескольких лет работы его профессиональные навыки постепенно улучшились, и он, возможно, добился некоторых небольших достижений, и люди будут становиться все более и более уверенными в себе. В это время, если вы не можете всегда поддерживать менталитет «пустой чашки», эта уверенность в себе постепенно перерастет в самоуспокоенность. Самоуспокоенность часто проявляется в том, что они воспринимают предложения других людей как критику на работе, не принимают никаких возражений, не имеют мотивации искать знания в обучении и всегда сравнивают свои сильные стороны со слабостями других. На самом деле самоуспокоенность в какой-то мере будет у всех, и самое страшное, что они не знают или даже не хотят признавать самоуспокоенности.

Принцип поддержания «менталитета пустой чашки» требует от нас постоянного самоанализа и самоанализа.. На работе общение с одноклассниками разного уровня или оценка на 360 градусов помогут нам более объективно оценивать себя. В горизонтальном сравнении посмотрите на этих отличных одноклассников и изучите преимущества других. В процессе обзора проекта или кода многие студенты часто враждебно относятся к вопросам и предложениям, поднятым другими. Неправильно думать, что другие придираются и нацеливаются на вас. Конечно, в некоторых отношениях мы действительно можем мыслить глубже, чем другие, но это не значит, что мы можем быть вдумчивыми во всех отношениях. Для предложений других людей рекомендуется использовать критическое мышление, упомянутое в принципе «хороших вопросов», чтобы тщательно проанализировать и смиренно принять эти хорошие предложения.

Работа и учеба подобны «прокачке уровня и борьбе с монстрами»: чем больше у вас навыков, тем легче дойти до конца. Сохранение менталитета пустой чашки позволяет нам открыть много новых способностей, которые мы не замечали раньше, и все, что нам нужно сделать, это изучить их и превратить их в часть нашего набора способностей.

Суммировать

Это десять основных принципов работы и учебы, которые я кратко изложил. Некоторые из них сосредоточены на отдельных способах ведения дел, таких как «осознание владельца», «концепция времени», «начать с конца», «мышление по замкнутому циклу»; есть только две вещи», «приоритет дизайна»; некоторые сосредоточьтесь на командном или индивидуальном повышении производительности, например, на «балансе P/PC», «умении задавать вопросы», «менталитете пустой чашки». Эти принципы представляют собой опыт, который я постоянно обобщал в своей работе и учебе на протяжении многих лет. Я надеюсь, что эти принципы помогут вам и направят вас, когда вы столкнетесь с выбором.

Работайте и живите по принципам, чтобы сделать себя и свою команду сильнее.

об авторе

Юнпэн, который присоединился к Meituan в 2014 году, последовательно участвовал в построении системы цепочки поставок отелей Meituan и системы распределенного планирования, а теперь отвечает за создание системы управления взаимоотношениями с клиентами Meituan и основных информационных услуг.