Тихий кризис в разработке софта

https://medium.com/@billjordan1/the-quiet-crisis-unfolding-in-software-development-cffbdafbf450#.h05834k8d
  • Перевод


Обо мне


Я работаю в сфере разработки программного обеспечения 28 лет. Моя нынешняя должность — старший директор по развитию программного обеспечения консалтинговой компании в Остине, штат Техас. Я работаю на этой должности чуть более шести лет.

Мой рост был изначально технического характера — я начинал как программист-аналитик как только закончил колледж. Одним из моих любимых хобби в те времена было высмеивание глупости менеджмента. Лишь позже я обнаружил у себя способности к менеджменту и осознал, что мне это действительно нравится.

Во Вселенной работает довольно жестокий вид кармы.

В моем нынешнем положении в качестве старшего директора по развитию программного обеспечения у меня есть 6 менеджеров по развитию, которые отчитываются передо мной. Только в моей организации около 50 разработчиков программного обеспечения. У нас завидно низкая текучесть кадров и очень высокий уровень удовлетворенности клиентов.

За эти годы я поделился со своими подчиненными и их непосредственными подчиненными теми же выводами, которыми я собираюсь поделиться с вами сейчас. Эти выводы — это выстраданная мудрость, а не то, что я интуитивно знал или читал. То есть, я узнал это, пройдя через трудный путь.

Поддержка публикации — компания Edison, которая разработала систему обсчета дорожного трафика на перекрестках и приложение обмена заказами такси.

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

Почти во всем виноват плохой менеджмент или может его лучше назвать причудливым менеджментом. В прошлом я был виноват так же как все, пока я не обнаружил и не усовершенствовал базовый набор методов, которые по большей части приводят к тому, что все становится на свои места — по крайней мере, по моему опыту. Никаких обещаний. Поехали!

Будьте осторожны с высокими показателями


Безусловно, вы решили, что некоторые разработчики в вашей команде отличные исполнители. Это обычно те разработчики, которые работают быстро. Менеджеры обычно выбирают и предпочитают этих разработчиков для проектов.

На самом деле отличных исполнителей очень мало и они встречаются крайне редко. Скорее всего у вас их нет. Вы можете думать, что есть и будете сильно ошибаться.

Готов поспорить, что ваши отличные исполнители добиваются таких результатов продуктивности путем технического долга в приложении намеренно или ненамеренно. Они экономят время на дизайне и архитектуре вещей разных уровней (от низкой к высокой — объектов и иерархий носителей, изменения схемы базы данных и т. д.), отсутствии адекватного тестирования и разработке кода, который трудно читать, поддерживать и расширять.

Такие высокопроизводительные исполнители на самом деле обладают очень плохой продуктивностью, если учитывать расчет совокупной стоимости владения. Но если это стартап, где время выхода на рынок имеет наивысший приоритет, тогда обратите внимание именно на вышеупомянутых исполнителей, только пристально следите за дизайном и кодом.

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

При наличии должного контроля и руководства, в долгосрочной перспективе, так называемые высокопроизводительные исполнители станут лучше и счастливее. Общая производительность вашей команды ускорится и улучшится.

Поощряйте продолжительное улучшение продукта


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

Стимулируйте разработчиков улучшать приложение, в то время как они работают над своими проектами. Примерами улучшений является создание объектов для повторного использования из скопированного и вставленного кода и разбивание больших объектов, которые трудно поддерживать, на объекты поменьше, с которыми легче работать по отдельности. Улучшите схему базы данных, даже если это довольно трудно сделать в кратчайшие сроки. Удалите старый и ненужный код. Обновите пользовательский интерфейс, чтобы улучшить опыт пользователей — иногда даже просто изменив пару слов можно заметить большую разницу.

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

Когда склонность к постоянным улучшениям станет частью ДНК вашей команды, результаты вас поразят. Но дайте время на то, чтобы они проявились, это не произойдет в одночасье. Это также значит, что руководству нужно признать, что на это потребуется больше времени, так как разработчики будут работать над своими основными проектами и параллельно совершать постепенные улучшения.

Непрерывное совершенствование это не самостоятельный проект. Если вы сделаете его таковым, то вы, в конечном счете, найдете повод, чтобы полностью отказаться от него, потому что это влияет на сроки. Это должно быть чем-то, что разработчикам поручат делать во время того как они занимаются своими обычными делами. Это не похоже на сложные проценты. Постоянное совершенствование в конечном итоге перерастет в поразительные результаты.

Поощряйте право собственности на код


Неудивительно, что руководство любит уменьшать риск, рассматривая разработчиков как взаимозаменяемые виджеты. Обычно ожидается, что разработчики ознакомлены со всеми пунктами кодекса. Это уменьшает боль, когда какой-то разработчик покидает команду или компанию.

Это ложная экономия. Вашим сотрудникам нравится работать на вас — верно? — значит, оборот должен быть низким. Не учитывать тот факт, что разработчики могут уйти значит рассматривать нестандартный сценарий вероятных событий. Чтобы добиться лучших результатов, нужно рассматривать стандартный сценарий.

Оптимизация по общему сценарию означает, что разработчикам нужно дать основное право собственности на части кодовой базы и не позволять другим разработчикам менять этот код без одобрения владельца. Это приводит к более высокой производительности труда, поскольку любой разработчик, вероятно, будет знаком с кодом, с которым он обычно работает.

Это также поможет вам определить разработчиков, которые заслуживают отдельного внимания. Некоторые разработчики выпускают больше ошибок так же, как некоторые плотники производят некачественные кухонные шкафы. Например, если разработчик обладает основным правом собственности на пользовательский интерфейс, и вы найдете необычайно огромное количество багов, станет сразу понятно на что вам —  как менеджеру — стоит обратить особое внимание и возможно принять меры.

Распознавайте лидеров


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

Эти разработчики ваши истинные лидеры. Его или её коллеги уже проделали тяжелую работу выявления настоящих лидеров за вас. Эти лидеры должны быть признаны таковыми и требуют специального рассмотрения.

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

Эти лидеры также должны быть публично признаны таковыми. Их нужно поощрять за работу, которую они уже делают. Так им легче помогать другим разработчикам без обид — это теперь часть их официального описания профессии! — и она обеспечивает им признание, а это поднимает боевой дух. Без этого официального признания, оказание помощи часто может казаться им просто нежелательным бременем. Не позволяйте этому случиться.

Большинство компаний имеют большие накладки в качестве компенсации в таких должностях, как старший программист и ведущий разработчик программного обеспечения, так что финансовой мотивации слишком мало, чтобы отрицать эти акции. Не заставляйте ваших (зачастую стеснительных) истинных лидеров просить о повышении — просто сделай это. Глазурь на торте для вас — как их менеджер вы получите взамен верность и преданность.

Следите за ложными системами показателей


Вы считаете количество работ, которые выполнил каждый отдельный работник? Просмотр этих расчетов находиться в свободном доступе для всех разработчиков программного обеспечения? Даже хуже: у высшего руководства есть доступ к этим данным? Прекратите делать это немедленно.

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

Если подсчет рабочих единиц это часть ваших ежедневных или еженедельных собраний, некоторые разработчики научатся решать простые вопросы, чтобы раздуть свой счет. У разработчиков программного обеспечения, которые впиваются в более трудные задачи, которые занимают больше времени, будет сознательно или бессознательно падать боевой дух. Это плохо сказывается на команде и продуктивности.

Еще хуже, когда исправления ошибок включаются в эти подсчеты, когда эти ошибки исправлены разработчиками программного обеспечения, которые сами же и сделали их изначально.

Например, рассмотрим проект разработчика#1, который вероятно будет выполнен за 10 дней без ошибок (или с малым количеством ошибок) и проект разработчика#2, который вероятно будет закончен через 5 дней, но в итоге в нем будут обнаружены 4 ошибки и на их исправление каждой уйдет по 2 дня. И все это без учета дополнительных затрат на поддержку и негативного опыт клиента в результате этих ошибок.

В таком случае разработчик#1 сделал только одну работу за 10 дней, а разработчик#2 пять (сам проект + исправление 4 ошибок) за 13 дней. Кто из них более продуктивен? Ваша система показателей, очевидно, лжет вам. Не доверяйте ей и ни в коем случае ее не афишируйте.

Лимит прерываний


Некоторые сотрудники не осознают, какое влияние они оказывают на других членов команды и часто отвлекают их от работы одним быстрым вопросом или хуже. Приучите вашу команду общаться таким образом, чтобы перерывы были сведены к минимуму: электронная почта, чат (если ваша команда не использует чат, то им стоит начать), мгновенные сообщения, телефонные звонки.

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

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

Предпочитайте отдельные рабочие места


Все мы видели фотографии офисов открытого типа, где разработчики программного обеспечения не могут протолкнуться и большинство из них сидят в наушниках в жалкой попытке хоть как-то сосредоточиться.

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

Иногда возникает проект, в котором требуется тесное сотрудничество. В большинстве офисов есть конференц-залы, которые могут быть временно перепрофилированы под открытые офисные пространства.

Поощряйте эксперименты


Мы все слышали о знаменитом 20% времени Google, благодаря которому стало возможно существование Gmail, и все это переросло в успешный онлайн бизнес по разработке приложений.
В то время как у большинства компаний нет огромных денежных ресурсов, чтобы действительно реализовать политику 20%, эксперименты, тем не менее, периодически следует поощрять и поддерживать. Разработчики программного обеспечения не лишены хороших идей и имеют особый опыт, а соответственно у них хорошее чутье касательно приложений, которые могут быть улучшены и расширены.

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

Позволяйте сотрудникам уходить


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

Заставляя сотрудников остаться в группе, вы никогда не добьетесь ничего хорошего. Это повлияет на их моральный дух, который влияет на моральный дух всей группы. Также вполне вероятно, что они станут работать менее эффективно и, в конце концов, просто покинут компанию. Любой менеджер, который не позволяет своим сотрудникам уйти, совершенно не понял, как произвести наилучшее соотношение счастья и продуктивности своих сотрудников, и это ошибка новичка, которую слишком часто совершают даже опытные менеджеры.

Никогда не отклоняйте небольшие просьбы


Ваш сотрудник хочет монитор побольше? Купите. Они хотят определенную клавиатуру? Купите. Они хотят работать из дома каждую среду и это их личное требование? Разрешите. Они хотят Мак вместо ПК? Дайте им его.

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

Отмените годовые и полугодовые отчеты


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

Вы не лучше ваших сотрудников


Разработка программного обеспечения это работа. Управление разработкой программного обеспечения это работа. То, что ваши сотрудники отчитываются перед вами, еще не значит, что вы умнее или лучше них. Многим разработчикам программного обеспечения, осмелюсь сказать, большинству разработчиков программного обеспечения нравится быть разработчиками. Не путайте и не позволяйте вашим работникам путать менеджмент с карьерным ростом — это просто другая работа, даже если за нее платят немного больше. Одна из худших вещей, которую вы могли когда-либо услышать, это как сотрудник говорит, что его карьера застопорилась, потому что его не повысили до менеджера. Нет ничего плохого в одной профессии на протяжении всей жизни, она держит ваш мозг в тонусе, а разработка программного обеспечения остается выдающейся карьерой. Разработчики должны хотеть попасть в менеджмент только по одной причине — потому что они хотят этого, а не потому что считают это шагом вперед.

Не делайте скидку разработчикам помладше или разработчикам постарше


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

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

Не заводите глупые дресс-коды


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

Теперь человечество знает, что одежда не улучшает продуктивность или успех компании. И, конечно, единственными мужчинами, которые носят галстуки, должны быть банкиры или юристы. Ладно, я шучу о той последней части — немного. Позвольте вашим сотрудникам одеваться комфортно. Для кого-то это будут джинсы и рубашка, а для кого-то бизнес-стиль. Они взрослые люди и вы должны позволить им решать.

Обобщение


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

Перевод: Диана Шеремьёва
Edison
386,00
Изобретаем успех: софт и стартапы
Поделиться публикацией

Комментарии 56

    +11
    >You probably don’t have one on your team. <-> Вероятно, вы не единственный человек в команде.

    Осспидяаа…
      +8

      Ну, или


      unhappy employees and unhappy users

      переведено как


      несчастным сотрудникам и несчастным пользователям

      На всякий случай поясню. В данном случае unhappy переводится как недовольный.


      Неделя посредственных переводов на хабре.


      Что самое неприятное — автор перевода в коментариях не появится, за косяки не извинится и, наверное, даже не поправит статью.

        0
        Ну, «не единственного человека» таки поправил.
          0
          А что особенного? В чем здесь большая разница между несчастным и недовольным? Перевод может наделяться и собственной стилистикой.
          По мне, есть разница между обращением «несчастного» человека и «недовольного».
          Второе уже является пассивной агрессией, а «несчастный» может быть и вполне лояльным.
          Так что, я думаю, автор правильно перевел стилистически.
            0

            Сначала вы спрашиваете в чём тут разница между несчастным и недовольным, а потом отвечаете на этот вопрос. И я с вашим ответом полностью согласен. И из статьи видно, что автор не имел в виду вполне лояльных несчастных пользователей и программистов. Что касается собственной стилистики перевода — не знаю — знаю только, что смысл искажать нехорошо.


            А вообще по поводу перевода слова unhappy дадим слово профессионалам. В данном случае — Зализняку.


            А уж самый гигантский перекос — когда английское happiness переводят как счастье, I’m happy переводят как я счастлив. I’m happy значит, что я сейчас себя комфортно чувствую, больше ничего.

            Вот ссылка на источник.

          0
          Я только теперь понял смысл того странного предложения.
            +1
            Несмотря на все усилия, технический долг будет начисляться: особенности вытекают в то, что их применение ведет к ужасным результатам. Ошибки исправляются быстро и «грязно», у менеджмента нереальные сроки, требования изменены – все мы проходили через это.

            Сравните с оригиналом:
            Despite your best efforts technical debt will accrue: features are grafted onto the application with ugly results, high priority bugs are patched in a quick and dirty fashion, management has unrealistic deadlines, requirements change — we’ve all been there.
            перевод
            Как бы вы не старались, технический долг будет накапливаться: фичи имплантируются в приложение с отвратительными последствиями, высоко-приоритетные баги быстро патчатся говнокодом, руководство ставит нереалистичные сроки, требования меняются — мы все проходили через это.
              0
              Спасибо.
                0
                фичи имплантируются в приложение с отвратительными последствиями

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

                высоко-приоритетные баги быстро патчатся говнокодом

                Или «серьезные ошибки исправляются на скорую руку». Это цензурный вариант quick and dirty fashion'а. К тому же, высокоприоритетной является не сама ошибка, а работа по ее устранению.

                руководство ставит нереалистичные сроки

                Скорее, «оперирует нереальными сроками»: «has» не подразумевает, что эти сроки спускаются исполнителям. Может иметься в виду, что исполнитель, наоборот, доложил неверный срок.
          • НЛО прилетело и опубликовало эту надпись здесь
              +2
              Да, при всех огрехах перевода сама статья великолепна.
                +1
                Качественный продукт, к сожалению, не всегда цель разработки… А если качество продукта и профессиональная комманда не ваши истинные цели — то данные советы вам только навредят :(
                  0
                  это по сути ответ на мой риторический вопрос ниже, только далеко не все могут признаться в своих истинных целях
                +2
                Люблю такие статьи. Кажется, что это все и так очевидно, но почему-то не используется. А тут всё собрано. Спасибо
                  +4
                  На самом деле понятно почему не используется. У владельцев бизнеса, как правило, мотивация — не сделать качественный продукт, а получить хорошие показатели (чтобы уровень акций вырос, чтобы владельцам бизнеса было что показать и т.д. и т.п.) И чем больше бизнес — тем это стремление сильнее.

                  А если вы последуете рекомендациям из статьи, то выяснится что да — у вас отличный, устойчивый бизнес, но пойти и продать кучку акций, чтобы купить себе Порше вы не можете. Показателей нет, объяснений как мы будем «завоёвывать марсианский рынок» — тоже. Ну и куда это годится? Нееет, брат, с таким настроением ты слона не продашь!
                    0
                    А это всё очень по разному, когда делаешь продукты для внутри корпоративного пользования, это одно, а когда аутсёрс контора клепает продукты на заказ, для них «технический долг» оплатит клиент :-)
                      0
                      Если контора достаточно большая, то получается такой себе «внутренний аутсёрс»: ты делаешь что тебе говорят используя «самых эффективных» исполнителей, а затем — уходишь в другую команду, чтобы их тоже «подтянуть» (как вариант — продаёшь свою компанию кому-то, после чего неудачи можно уже списывать на «проблемы интеграции»). В результате все плюшки достаются тебе, а шишки — твоим последователям. Если делать это достаточно успешно, то можно дорасти до руководителя корпорации с сотнями тысяч сотрудников… правда после этого уходить будет некуда, так что твоя слава «великолепного менеджера» немного померкнет — но у тебя к этому времени будут уже десятки (а то и сотни) миллионов на счету. См. Элоп, Стивен.
                  +7
                  Он существует! Адекватный руководитель существует!
                    +3
                    Я такого руководителя за всё свою 25-летнюю карьеру не встречал. И тоже прошёл тот-же путь. Что-бы хоть как-то приблизиться к идеалу, который тут описан, мне пришлось открыть собственную компанию… Только вот пока, я не могу позволить себе постоянных сотрудников.
                    +14
                    Спасибо! Интересная статья. Только перевод местами запутывает.
                    «Ваш сотрудник хочет монитор побольше? Купите ему один».
                    А если сотрудник попросит два? Не покупать?
                    В оригинале написано так: «Does your employee want a bigger monitor? Buy them one».
                    Т.е. «купите им его». Здесь слово «one» использовано в качестве местоимения.
                      +6
                      Который перевод подряд в тексте этого автора находятся тьма косяков и кривых фраз, явно написанных роботом. Чего стоит только оборот «одним быстрым вопросом или хуже. »

                      И этот переводчик — в рейтинге пользователей находится на первом месте. Давайте, расскажите мне о саморегуляции сообщества…
                        +5
                        А общество, в общем, неплохо саморегулируется. Вы, как бы, не на то смотрите: качество перевода тут не так важно, важно что оригинал хорош. А что перевод плох — ну так что ж теперь делать, лучше так, чем отлично переведённая статья «ни о чём».
                          0
                          А что перевод плох — ну так что ж теперь делать

                          Плюсовать хорошие переводы и минусовать плохие. И коментарии к статьям с плохими переводами писать только по поводу качества переводов, не обсуждая саму статью. И, конечно, делать хорошие переводы самим.


                          лучше так, чем отлично переведённая статья «ни о чём».

                          Лучше — ссылка на первоисточник без перевода, чем вот такой перевод.

                            –1
                            Эмм, а можно, вы просто найдёте хорошую статью, здесь положите ссылка на неё, а мы уж сами как-нибудь в яндекс-переводчик ссылку вставим?
                              +3
                              Не работает. Как ни плох обсуждаемый здесь перевод, но он всё равно лучше того, что все онлайн-переводчики порождают.
                            –3
                            Клёво, если сообщество помогает и подсказывало как лучше перевести тот или иной момент. Так многие и делают, за что им большое спасибо.
                              +11

                              Сообщество указывает вам на грубые ошибки, которыми пестрят ваши переводы, а не на то как лучше перевести тот или иной момент.


                              Только толку от этого, если LukinB или вот вы лично, как правило, не обращаете на коментарии внимания. Что вас что его зачастую даже в коментариях нет.


                              Я написал несколько коментариев по поводу качества перевода с указанием конкретных ошибок. Знаете, что происходило дальше. Дальше во-первых моментально мой коментарий ловил один минус, а во-вторых один минус приходил мне в карму. И собственно вот. Ни о каком спасибо речи даже нет.

                                0
                                По своему опыту на хабре скажу, что отправлял корректировки авторам приватными сообщениями, а не комментариями к статьям.
                                Минус никогда за такое не получал, это же приват.
                                А автор ставил плюс в карму, за помощь.

                                Наверное это выход, если душа требует.
                                  0
                                  Напротив, никогда не мог понять, отчего некоторые не любят публичных корректировок. Какая разница, будет ли ошибка зафиксирована публично, или нет?
                                    +1
                                    Мне как читателю будет неудобно: много ненужных по сути комментариев.
                                      +1
                                      Потому что вместо обсуждения смысла статьи начинается обсуждение оформления. Поток корректировок, часто повторяющийся.
                                        0
                                        Если статья важная и интересная, комментариев к ней будут тысячи. Пяток из них по теме оформления — ничто. Напротив, если их мало, и в основном, об оформлении, значит обсуждать нечего, люди ничего по сути добавить не хотят.
                                          +1
                                          Вашими бы устами… Вы про bikeshedding никогда ничего не слышали? Нет? Счастливый человек.

                                          В комментариях к статьям обсуждают, зачастую, чего угодно — только не то, что «по сути» статьи…
                                            0
                                            Да мы тут как раз тем самым обсуждением сарая и занимаемся. Люди разные, внезапно. Мне несложно прочесть комментарии и просто отсеивать байкшедные ветки, обычное ограничение мтодом ветвей и границ, таксзть. Потому и удивляюсь — неужели кого-то это так раздражает.
                                              0
                                              Я боюсь вы избалованы Хабром с его системой кармы и не представляете что творится на сайтах где нет такого жёсткого отбора.

                                              Когда 99% комментариев — чушь, то «методы ветвей и границ», внезапно, начинают работать из рук вон плохо.
                                                0
                                                Так мы-то про Хабр говорим, контекст задан.
                                                  0
                                                  Ну так вы уж определитесь: хотите ли вы, чтобы за прегрешения (типа публичных корректировок) «били по рукам» или чтобы вам приходилось копаться в куче дерьма?
                                                    0
                                                    Из призыва определиться следует, что я будто бы высказал что-то неоднозначное или какие-то взаимоисключающие параграфы. Тогда как я изначально высказал свое удивление по поводу неприятия публичных корректировок (т.е. косвенно поддержал публичные корректировки), а затем указал, что мне лично не составляет труда отсекать непродуктивные или неинтересные мне ветки, и поэтому, мол, мне непонятна (читай — мне понятны мотивы других, но считаю неприязнь необоснованной, проблему множества комментариев — малозначимой) неприязнь к публичным корректировкам.
                                                    То-есть, я свою позицию высказал однозначно и достаточно четко.
                              +1
                              > Кроме того, одна из принципиальных позиций, которую должны занимать менеджеры, вне зависимости от того понимают они это или нет это оборона.

                              Оборона? Кого от кого?
                                +2
                                Оборона от заказчика, от пользователя, от внешнего мира и т.д.
                                Я некоторое время работал разработчиком в банке. Так вот меня посадили в центре опен спейса среди бухгалтеров, экономистов и сотрудников кол-центра. Вот например от этого нужно оборонять.
                                  +1
                                  Жестоко, я сисадмином в подобных условиях работал.
                                0
                                > Если у вас нет бюджета на такие запросы, пришло время, чтобы начать искать работу в другой компании, потому что закон среднего и высшего звена нарушается.

                                Что за закон среднего и высшего звена?
                                  +9
                                  Не обращайте внимание. Как тут уже все заметили — перевод халтурен до невозможности. В оригинале там нет никакого закона, просто говорится о том, что если у вас нет бюджета, которым вы, как менеджер, можете распоряжаться, то менеджмент на среднем и высшем уровне никуда не годится и, соответственно, стоит поискать другую работу.

                                  Исходная посылка проста: менеджмент — это управление людьми, а для этого нужен кнут и пряник. Если у вас нет бюджета на то, чтобы улучшить жизнь ваших подчинённых и остался только кнут, то уныние и посредственность — всё, что у вас через какое-то время воцарится. Оно вам надо?
                                  +18

                                  Молодцы, ведёте себя именно так, как не рекомендуется в статье: показатели блога растут (n статей в месяц) и статьи живые (к каждой куча комментариев).
                                  А на деле, перевод материала — полное дерьмище, а все комментарии о том, чтобы перестали публиковать такие переводы.

                                    +1
                                    > Эта статься очень долгий и запутанный способ помочь вам узнать, как заботиться о своих сотрудниках по разработке программного обеспечения лучшим образом.
                                    > Если вы будете должным образом заботиться о своих сотрудниках, то они будут заботиться о вас

                                    Нужно больше заботы!
                                      +4
                                      Мдя, перевод, конечно, ещё тот. Но если сейчас вы закидаете переводчика тухлыми помидорами, никто больше не захочет вообще ничего переводить, ни хорошо, ни плохо. А нет ли где места, где все залогинившиеся могут редактировать переводную статью? Этакая википедия переводов.
                                        +2
                                        Широко распространенная практика на Хабре — писать в личку в формате: кривое (плохо переведенное) предложение + ваш вариант перевода того же самого предложения. Я стараюсь оперативно исправлять.
                                        +2
                                        господа, я конечно понимаю что перевод не очень, но почему-то я не вижу других переводов этой статьи, тогда может хватит его обсирать и начать обсуждать?
                                          +1

                                          Если бы это был первый плохой перевод — возможно, последовать вашему совету имело бы смысл — но это не первый плохой перевод и не второй. Причём первая ссылка — перевод профессионального переводчика.


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


                                          Казалось бы — перепосты в явном виде запрещены правилами хабра, но, оказывается если перепост назвать переводом — это решает проблему.


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


                                          P. S. Хотелось бы отдать должное автору текущей публикации. Он появляется в коментариях и что-то пытается объяснить. Профессиональный переводчик, в отличии от MagisterLudi вообще фактически плюнул сообществу в лицо.

                                          +3
                                          Я долгое время считал себя ненормальным, спасибо, теперь я знаю что это не так.
                                          Но один вопрос всетаки остался, если все описанное тут очевидно мне, человеку с 13 летним опытом программиста — почему, мать его, это тайна за семью печатями для той армии менеджеров что окружает меня???
                                            0
                                            Потому что их учат по другим методичкам…
                                              +2
                                              Потому что есть тёмная и светлая сторона менеджмента.

                                              На светлой — люди, продукт, команда, лидеры, поощрения, опыт, навыки, улучшение.
                                              На тёмной — ресурсы, доход, расход, план, факт.

                                              Нам, как разработчикам, не хочется думать о тёмной стороне, о том что мы ресурсы, мы совершенно одинаковые, у компании от нас только прямые расходы и косвенные доходы (особенно, когда нас 50 и нет ярко выраженного личного вклада).

                                              Нам, как владельцам продукта, не хочется думать о светлой стороне. Что там незаменимые специалисты, эксперты в разработке ПО, что один лидер по стоимости равен трём нелидерам, что в целом надо накостылить из гавна и палок *нечто*, что хомячки уже вчера готовы были платить за этот кодобред.

                                              Потому что это нам неприятно.
                                              Противоречит нашему мировозрению.
                                              Вызывает много вопросов, когнитивный диссонанс, выход из зоны комформа, попытку взглянуть на мир чужими глазами.

                                              Тех джедаев, которым удалось не перейти туда или сюда, они балансируют между светлой и тёмной стороной одинаково успешно — их мало. А ещё приверженцы светлой и тёмной одинаково недолюбливают их за недостаток силы.

                                              Книги по светлой стороне: «Программист-прагматик», «Программист-фанатик», «Работа мечты», «Как стать организацией осознанного развития», «Клиенты на всю жизнь», «S.U.M.O.», «Открывая организации будущего».

                                              Книги по тёмной стороне не подскажу, не так хорошо в них ориентируюсь, но иногда приходится сталкиваться. Рваный след от неудачных встреч с этой силой. Обрывочные сведения.
                                              +2
                                              Очень грамотно написано и данная проблема действительно есть. Надо дать возможность программисту полностью раскрыться и вы удивитесь полученному результату! Поощряйте творчество среди сотрудников и дайте им больше свободы. Тогда результат будет выше и текучка минимальна (о чем и было сказано в начале статьи, и это важно!)
                                                0
                                                Сотрудники будут такими, каким ты в них веришь.

                                                Если веришь, что они будут на работе лоботрясничать, значит они будут играть в игры и отвлекаться на посторонние дела, постепенно один за другим («А чё я вкалываю, если он весь день играет и получает такую же з/п», «Неохота думать, лучше постреляю»)
                                                Если веришь, что они будут развиваться и поддержишь в этом, то на отлынивающих от работы будут косо смотреть и постараются из коллектива выжить.
                                                  0
                                                  Ссылки по теме:
                                                  https://www.youtube.com/watch?v=cKH6ZsJO2zM
                                                  https://ru.wikipedia.org/wiki/Магическое_мышление
                                                  https://www.youtube.com/watch?v=atIwagMBDi4

                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                              Самое читаемое