Программисты и менеджмент

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

Более того, я и сам, бывало, я вдруг, совершенно неожиданно получал письмо от хорошего грамотного разработчика, о серьёзных управленческих ошибках руководства, которые подрывают мотивацию команды и её веру в светлое будущее. В письме обычно давался разбор какой-нибудь цепочки ситуаций, а затем сообщалось о том, что автор устал и не видит для себя больше возможности работать в компании. Я не наивен и понимаю, что, скорее всего, разработчик увидел где-то в другом месте, например, более заманчивые финансовые перспективы. Однако, не стоит упрощать – иногда люди переходят в другую компанию на ровно такую же зарплату, а бывало (и к нам и от нас) даже и с потерей.

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

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

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

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

Но и после этого у Клиента могут всплыть новые ошибки. Он сообщает о них. Тестировщики их локализуют – и к программисту поступает следующая информация: в таком-то месте программы имеется такая-то ошибка, которая приводит к таким-то неприятным последствиям.

Теперь представьте себе, что об обнаруженных в вашем коде ошибках все молчат, ничего вам не сообщают. Но зато обижаются на всё новые и новые ошибки, рассуждая следующим образом:
«Ну что такое? Этот парень совершает всё новые и новые ошибки! Как можно отдавать нам ПО с этими багами? Просто поток ошибок! Да он нас совсем не уважает! Наша мотивация от работы с ним опускается всё ниже и ниже…».
Наконец принимается решение «Это терпеть больше нельзя! Мы больше не хотим с ним работать!»
Как вы думаете, правильно ли так поступать по отношению к программисту? Получится ли у него хороший код без обратной связи об ошибках и необходимости тех или иных улучшений? Есть ли перспектива добиться хорошего результата при таком подходе? Думаю, что ответ – очевиден.

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

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

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

Ровно то же касается и менеджмента. Следуя потребностям наших Клиентов, мы в стремлении к улучшениям вынуждены менять нашу компанию, принимать различные управленческие решения, вносить изме6нения в её код. Иногда мы совершаем ошибки. Программисты знают, можно написать тысячу строк правильного кода и ещё пару строк, которые сделают неработоспособной всю программу – и то, что написано сейчас, и то, что написано раньше, вами самими и другими людьми до вас. Рецепт борьбы с этой неизбежной неприятностью прост: обнаружение ошибки, информирование о ней, локализация, исправление.

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

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

То есть, Клиент не говорит: «Ребята, здесь у вас ошибка, поправьте, пожалуйста», а молчит и всё больше обижается за неправильное отношение к его нуждам и чаяниям. Он считает несправедливым, что ему отдают код с ошибками, а потом у реально тысячи человек мучаются. А справедливым он считает — назвать это свинством с нашей стороны.
Представьте, когда у нас Клиент — правильный, мы, совместными усилиями, пройдя через определённые трудности, всё равно, в конце концов, можем создать действительно отличную систему, которая будет всё больше и больше отвечать его потребностям, с которой ему будет всё более и более комфортно.

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

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

От Клиента нам нужна оплата наших услуг в обмен на удовлетворённость его нашим продуктом.

От Разработчика нам нужен эффективный труд в обмен на удовлетворённость его работой в нашей компании.

Клиент, в идеале, хотел бы, чтобы мы работали за 20000 рублей в месяц и сразу выдавали то, что ему нужно, желательно не через год, а через пару недель, и чтобы сразу всё работало идеально и без ошибок, и без дурацких вопросов, как ему лучше — так или так («Неужели Вы сами не знаете, чего я хочу? Вы же называете себя специалистами!»)?

Мы с вами понимаем, что это невозможно. Мы не станем работать за 20000 рублей в месяц. Многие вещи даже гений не сделает за пару недель, поскольку на эту работу нужно полгода команде из трёх человек, если повезёт и не всплывут неизвестные трудности. Программы же работают так, как нужно только после нескольких итераций, исправления многих ошибок и внесения множества предложенных Клиентом дополнительных улучшений. Но осознав, что за хороший конечный результат мы отвечаем оба – и Исполнитель, и Заказчик, что этот результат возможен только, как плод совместных усилий и компромиссов, правильный Клиент получает, в конце концов, то, что ему нужно, то, что обеспечивает ему конкурентное преимущество перед соперниками.

Программист в идеале хотел бы, чтобы ему платили тысяч 150 рублей, при этом никогда не было переработок, он мог бы заниматься не тем, что нужно Компании, а тем, что ему интересно. И желательно, чтобы штрафы, которые иногда бывает вынуждена платить компания за критические ошибки в его коде, его не касались вообще никак. Компания, у которой в результате его косяков стало на 300 тысяч рублей меньше на закупку нового оборудования, мебели и т.д., должна просто объяснить команде проекта, которая получает ЗП много меньшую, чем программисты, но зато получает премию от дохода проекта, что они теперь получат на всех на 100 тысяч рублей вознаграждения меньше. Но программистов, которые отдали Клиенту вообще никак не оттестированный код, нельзя оштрафовать даже на пару сотен, то есть на процент от потерь компании, потому что им так некомфортно – они бы хотели, чтобы ответственность — финансовую, даже символическую по сравнению с потерями других, программисты не несли в любом случае (как говорится, «штрафы разработчиков демотивируют»).

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

Невозможно всегда избегать ответственности за промахи. Если многие люди в компании реально пострадали и в моральном плане (Клиент, с которым они общаются постоянно и от которого зависит успех их работы, считает, что его грубо подставили, потому что он простоял целый день и каждый из 200 агентов и пары десятков супервайзеров недозаработал в этом месяце по 5% своей зарплаты, а владелец 10% своей прибыли — и все на них злы), и в материальном плане: доход проекта стал заметно меньше – и их вознаграждение стало заметно меньше. Команде проекта (это много людей), которая честно трудилась и на которую обиженный Клиент водрузил и моральную и материальную ответственность, невозможно объяснить, почему за этот косяк, к которому они не имеют прямого отношения, должны отвечать только они и совсем не должен отвечать тот, кто его допустил. Заметьте, речь не идёт о том, что код должен быть безбаговым – речь идёт о том, что он попал Клиенту вообще без тестирования.

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

Но если программист, так же как и Клиент в его случае, не будет ждать чуда, не будет надеяться, что ему какие-то дяди-менеджеры организуют всё так, что за одну и ту же работу, за которую он не хочет нести существенной ответственности, он почему-то со временем будет получать всё больше и больше, а, напротив, будет указывать менеджерам на их ошибки, помогать локализовать проблему, подсказывать своё видение решения, то мы, как и в случае итерационного создания ПО, будем итерационно улучшать нашу организацию, нашу ответственность и наши методы мотивации. Мы нарастим и укрепим с таким трудом завоёванное нами сегодняшнее лидерство. И Клиенты будут платить нам больше и охотнее. И ЗП программистов будет реально расти, потому что эффективность их будет расти. Не только благодаря росту индивидуального мастерства, Но и благодаря более правильной, более рациональной организации нашей работы. Ведь наилучшая стратегия для роста зарплаты – это рост эффективности и качества.

Есть такой известный пример, иллюстрирующий положение лидера. На чемпионате по гольфу призовой фонд для победителя составляет один миллион четыреста тысяч долларов, занявшему второе место выплачивают шестьдесят тысяч, а третьему только двенадцать тысяч. При этом результат первого всего лишь на полпроцента лучше второго, и на полтора процента лучше третьего. Ровно те же правила действуют в бизнесе. Лидер, который на пару процентов лучше второго, получает во много раз большее вознаграждения. Нужно стремиться быть первым – и награда не заставит себя ждать. Мы делаем очень сложный бизнес, в котором все сильно зависят друг от друга. Может 40 человек очень стараться и работать много и честно, а неправильные действия одного испортить труд многих. Помните пословицу про ложку дёгтя в бочке мёда? Мы живём в 21-м веке и не очень понимаем, что такое дёготь. Предлагаю более понятно. В целой бочке повидла маленькая чайная ложка дерьма. Вряд ли вы, зная об этом, захотите это есть. Результат работы конкретного программиста может драматически влиять на результат работы всей команды разработчиков, внедренцев, менеджеров. Было бы здорово, чтобы мы совместно нашли способ повышения индивидуальной ответственности разработчиков, поскольку от этой индивидуальной ответственности зависит иногда множество людей. Представьте, что на автомобильном конвейере на одном из участков по сборке двигателей втулку цилиндра устанавливают с нарушениями технологии. Этот косяк обесценивает честную работу всех остальных участников процесса, потому что, независимо от старательной работы всех остальных, на выходе получается брак.
Правильный путь с моей точки зрения – не требовать освобождения от ответственности. Потому что она, всё равно, наступает и от неё освободить нельзя – можно только переложить её на других. Помните «Наказание невиновных, награждение непричастных»? Это же неправильная, гибельная стратегия! Нужно так организоваться, чтобы эта ответственность не наступала, потому что всё у нас – реально хорошо.

Условия, в которых мы существуем – объективны. И менеджеры ошибаются, точно так же, как и программисты, из лучших побуждений, из желания сделать систему лучше, дополнить её фичами, улучшить быстродействие, срезать углы в логике. Только через исправление управленческих ошибок можно сделать нашу систему лучше, а нашу жизнь интереснее и комфортнее.

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

У Клиентов иногда обнаруживается какая-нибудь серьёзная ошибка/проблема, которая не может быть поправлена влёт. Иногда, для того, чтобы ошибку/проблему разрешить нужны серьёзные усилия и много времени, поскольку бывает, что нужно, как в анекдоте «всю систему менять». Неумный Клиент иногда не понимает: «Я сообщил вам о проблеме уже 3 недели назад, а она до сих пор не исправлена! Вы ничего не делаете!». Он иногда не может уразуметь, что у нас есть очередь из задач на разработку, и мы не можем решать сразу все проблемы одновременно. Что проблема сложна и требует много человекомесяцев и внесения изменений в целый ряд взаимозависимых подсистем. Если он наберётся терпения, то, в конце концов, получит то, что ему нужно. И его система будет лучше, чем у конкурентов, потому что он помог нам сделать её лучше, чем у конкурентов. Вряд ли результат будет хорошим, если Клиент занимает позицию: «Я – Клиент и поэтому всегда прав. Не грузите меня Вашими проблемами – просто сделайте, чтобы я был доволен». Если Клиент для Вас – это слишком далеко (жаль, если это – так), то представьте на его месте тестировщика, который ничего не объясняет, на ошибки не указывает, просто требует, чтобы Вы сделали так, чтобы он был доволен. И притом прямо к следующей среде. Скажите, есть нормальные конструктивные перспективы у этой ситуации?

Вот и у нас, даже если сотрудники не молчат, этого не достаточно для решения всех проблем. Многие сотрудники и вправду искренне заинтересованы в улучшениях и дают менеджерам обратную связь о проблемах. Она — очень полезна и заставляет менеджеров осознать эти проблемы и искать их решение. Но я часто слышу следующее – «мы уже говорили об этой проблеме в мае, но воз и ныне там – в этой компании ничего не происходит» (читай: «и поэтому наша мотивация неуклонно опускается»)!

А разве мы сами не говорим Клиенту, что вот эту его проблему невозможно решить за две недели – нужны упорные и ДОЛГИЕ усилия целой команды. А иногда даже (какой кошмар!) мы осознаём проблему, но пока не придумали, как с ней справиться. Но обязательно придумаем (ещё не было так, чтобы мы, в конце концов, не решили поставленных перед собой задач!). Нужно помогать искать выход, и нужно быть терпеливым. Терпение – это добродетель, которая в правильном месте вознаграждается.

Два года назад в компании работали 70 человек. А сейчас в ней работает 250 человек. Все эти люди сильно зависят от работы программистов, то есть от вас. Им, для того, чтобы не вздрагивать по ночам, необходимо быть уверенным, что те, от кого они так сильно зависят – люди спокойные, рассудительные и ответственные. И не скажут в любой момент, вы — как хотите, а я – пошёл… Вот вам моё заявление об уходе. Обещания, которые Вы надавали в расчёте на меня, меня не волнуют. Что будет с коллегами, которые эти обещания подтверждали лично в глаза Клиентам, мне всё равно. Мне с ними детей не крестить.

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

Мы всегда с огромным уважением относимся к кандидатам, которые говорят: «Я хочу у вас работать, но у меня есть обязательства по старому месту и я должен их закрыть. Вы можете подождать?». Ответственность – очень важное качество, и мы всегда говорим: «Конечно. Мы потерпим. Закрывайте свои долги». Мы хотели бы, чтобы к нашим нуждам относились так же ответственно, как мы относимся к чужим. Своей просьбой отработать месяц-два вместо двух недель мы удерживаем ребят от неправильного поступка, за который потом (когда повзрослеют) им было бы стыдно.

Ещё раз повторю: Наша компания, наша организационная структура, наши процессы – это код, который мы пишем вместе. Давайте нам обратную связь, идеи об улучшениях, помогайте их воплощать – и мы будем гордиться своей компанией, потому что в ней будет работать комфортно и интересно.
Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 31

    +8
    Обнаружив, что разработчики часто довольно туманно представляют себе, как устроены «глобальные» бизнес процессы в компании, я решил попробовать объяснить разработчикам, с какими проблемами сталкиваются те, кто пытается организовать их труд и направить его в «мирное русло».

    C одной стороны согласен в том что психовать и разбегаться не конструктивно, с другой — в этом и смысл менеджмента чтоб организовывать работу разработчиков чтоб им не пришлось сталкиваться с этими проблемами. И чтоб эти проблемы разрешались до того как человек успеет написать разбор «цепочки ситуаций» — таких цепочек вообще не должно быть (так же как не должно быть багов в коде, ага).

    Это как если разработчик срывающий сроки пришлет проджект манагеру 15 тыщ строк кода со словами что вот этот момент не совсем понятен давайте подумаем вместе.
      +8
      Понравилось признание того факта, что менеджера тоже косячат. Согласен с этим. И, кстати, косячат не изредка, а основательно так: увольняют не того, принимают не того человека на работу. А расхлебывать потом всей команде. И еще требуют предсказывать будущее: «сколько времени у вас займет...».

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

      Та же ситуация и с менеджерами: менеджер должен признавать свои ошибки. Можно ведь раз в неделю собрать людей и спросить «ребята, где я сильно косячу, где облажался?» Можно объяснить разработчикам свою ситуацию, и всем вместе подумать над ее решением.

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

      Программисты любят менеджеров. Хороших менеджеров. Достаточно раз поработать под руководством хорошего менеджера, чтобы видеть всех говноменеджеров насквозь. Посредственный менеджмент — бич современной разработки.
        –1
        >И еще требуют предсказывать будущее: «сколько времени у вас займет...».
        ах какой менеджер негодяй, требует сроки назвать…
        +5
        Менеджмент не делает никакой полезной работы, и у него не должно быть ошибок. Цель менеджмента — чтобы всё внезапно не развалилось, и если менеджмент не делает хуже, это уже хорошая работа, даже если и не становится лучше.

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

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

          Менеджмент делает ошибки, они могут быть куда дороже и хуже багов — это правда, главное что-бы менеджмент как и любая другая роль, учились на этих ошибках…
            +3
            С удовольствием узнал бы об этой Цели.
              –2
              Цель — организовать чтобы работало.
              Чтобы вы не пинали балду.
              Чтобы было можно запускать ракеты в космос, а не мастерить каменные топоры.

              Во всех задачах, где один человек справится своими силами не может, требуется менеджер
                0
                Про организовать(рабочее место?) понятно, на то программист и наёмный рабочий.
                Если работник пинает балду — его выгоняют. В этом нет никакого секрета. Есть смысл ради этого платить ещё одному человеку зарплату?
                А как разработчик мастерит каменные топоры вместо запуска ракеты в космос? Менеджер сидит и указывает ему что писать и как? Да ладно?

                Ну а насчёт всех задач… Существуют старшие разработчики, архитекторы, тимлиды, они ведь не менеджеры? Но именно они координируют работу, и работают, создают полезный выхлоп, чего я бы не сказал о менеджере. Да вот вы вспомните университет к примеру — там несколько студентов без менеджеров делают то что им нужно — курсовой, к примеру.
                Нет, я согласен, менеджеры нужны, но ИМХО, их роль слишком переоценена. Америка стайл.
                  0
                  Кто выгоняет? Если управленцев нет?

                  Менеджер помогает организовать взаимодействие между людьми.
                  И чем больше коллектив тем больше энергии тратится на внутренние связи.
                  Так вот эти самые менеджеры-управленцы и призваны снижать затраты на коммуникации внутри коллектива.
                  Насколько эффективно они делают это другой вопрос.

                  А пример с топорами и ракетами был призван показать разницу между 1-2 людьми при работе с топорами и сотнями тысяч людьми при разработке ракет.

                  И для справки — team lead это во многом уже больше менеджер нежели разработчик.
          +4
          Эта проблема слишком распространена, но почему-то многие не могут понять причин, и борются со следствиями. Как правило подобные проблемы возникают из-за разного положения сотрудников в компании, как по обязанностям, так и по должностям. Сама модель «начальник-исполнитель», в этом случае начинает деструктивно влиять на весь процесс, и с ростом компании, весь механизм идет в разнос. Я не говорю, что все проблемы именно по этой причины, но отсутствие обратной связи как как правило из-за этого и возникает.
          Вот на примере этой статьи я снова вижу одни и те же ошибки, люди делят единый организм (компанию), на псевдоорганизмы (менеджмент и исполнители), и пытаются строить правила игры. Конечно, правила игры нужны, но вам в начальника поиграть, или делом заниматься? Если делом, то не создавайте искусственных преград в общении, и будем вам счастье. Не отдаляйтесь от сотрудников, но и не становитесь навязчивыми. Эти правила просты, относятся не только к программистам, а вообще к любой профессии.
          На эту тему недавно появилась замечательная, на мой взгляд, статья.
            0
            Более того — подозреваю, что в России Большее количество именно таких(больших) начальников, описанных в статье —
            будешь делиться с ними обратной связью, и только быстрее перестанешь работать в компании,
            но в том случае не ты уйдешь, а тебя уйдут. :)
              0
              Это и реальность и миф. Реальность да, так бывает, но эта реальность создает миф и подсознательный страх, что тебя могут уволить аргументировав это тем, что ты «зря что-ли зарплату получаешь!? вон Вася работает, и у него никаких проблем в коде нет, а ты мне только плохие новости и можешь приносить!».
                0
                А мне кажется, что обратная связь всегда нужна, но не все могут хорошо её донести. Как наглядный пример проблемы — сегодня на хабре есть свежая статья про собеседования и говорить причины отказа или нет.

                И ещё мне кажется, что хорошего профессионала, будь он хоть дворник, всегда где-то ждут. Есть повод для самосовершенствования :)
                И иногда нужно отдавать себе отчёт в том, что все в какой-то мере боятся неопределённости, особенно с возрастом, чем поиск новой работы и является.
                Так что говорить правду нужно. А проблему превосходности компании и плохого человека в менеджменте решать по мере желания, потому что над всеми есть начальник, а над самым верхним — жажда денег, славы и прочие :)
              +4
              > программистов, которые отдали Клиенту вообще никак не оттестированный код, нельзя оштрафовать даже на пару сотен
              Совершенно верно сказано. Организация рабочего процесса, позволяющая никак не оттестированному коду попадать в руки заказчика, — это вина только менеджера.
                0
                Вероятно, автор имеет в виду ситуацию, когда разработчик даже ни разу не запустил написанный код, и в итоге оказалось, что продукт не проходит даже проверку «на дым» — т.е. критический баг лежит на поверхности. В этом, конечно же, вина разработчика присутствует.
                А вот то, что такой продукт попал к клиенту — это конечно же вина менеджера, т.к. явно нарушен процесс.
                  +1
                  гм… а тестеров нанять? а самим посмотреть? я вообще себе ситуацию такую не могу представить, чтобы никто, кроме разработчика, не посмотрел на работу программы. однозначная ошибка в организации.
                    0
                    А тестировщики есть. И должны были проверить. Но процесс сбойнул и в итоге не проверил никто. Вообще никто. Т.е. косяк в процессе явно присутствует.
                    Но разработчик-то не проверил свой код — с этим что делать?
                      0
                      Выговор. При повторении во второй-третий раз — увольнение. Параллельно начинаем искать разработчика на замену.
                        0
                        объяснить. наказать, если предусмотрен соответсвующий пункт в контракте. но не только разработчика, а всех, кто был ответственнен за тестирование и огранизацию рабочего процесса.
                  +4
                  Обратная связь — дело, конечно, хорошее и нужное. Но прежде всего у рядовых сотрудников должна быть четкая уверенность, что их критика не приведет к мести со стороны обиженного начальства. И, конечно, одного честного слова начальства тут будет недостаточно. Одно из решений — анонимная обратная связь. Но и этого недостаточно, ибо все понимают, что очень часто критика легко вычислить просто по стилю письма…

                  Теперь по поводу обид на то, что «мы уже говорили об этой проблеме в мае, но воз и ныне там – в этой компании ничего не происходит». Если программистам дается новое задание, то предполагается что от них будут поступать какие-то сведения о продвижении дела. Ну, типа «мы сможем взяться за ваше задание через три недели — у нас уже есть очередь». Через три недели: «Мы взялись за задание, предполагаем сделать через месяц». Еще через две недели: «Работа идет по графику, но возможна задержка на три дня», ну и так далее. Нужна прозрачность. И это же хочется видеть у руководства. Программисты пожаловались, скажем, на то, что новые правила работы с документами отнимают слишком много времени, и в ответ, помимо «Спасибо, мы учтем ваше мнение» хочется слышать что-то конкретное — когда и как это будет рассмотрено и т.п.

                  Ну, и последнее. Я работю в Штатах, и мне совершенно дико слышать про штрафы сотрудников. Здесь такого нет, и я не понимаю, зачем они нужны. Если в результате клиент получил плохой продукт, то проблема лежит в процессе, который допустил это (а где QA? ) и в руководстве, которое такой процесс создало. Вина общая, штрафовать никого не надо.
                    +2
                    чтобы в программе было меньше ошибок, хорошие программисты пишут тесты. и получают обратную связь самостоятельно.

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

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

                    не надо жаловаться — работать нормально нужно.

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

                      Инициатива «работы с коллективом», думаю, должна исходить от менеджера. Просто потому что обычно менеджер является начальником.
                        +1
                        Открою вам одну страшную тайну. Хороших разработчиков очень мало, и мы/они очень капризные. И по большому счету все что нужно менеджерам это не мешать разработчикам, нужно просто научиться направлять энергию разработчиков в нужное для компании русло. Ну а любые попытки давления, штрафы и вообще любые действия которые «демотивируют разработчиков» приведут к вполне закономерной текучке кадров.
                        Я вообще считаю что штрафы это худшая мотивация не только для разработчиков но и для вообще всех работников.
                        Но если тетя Глаша из бухгалтерии боясь потерять работу терпит штрафы, а разработчики при этом «в наглую» и открыто говорят что не потерпят никаких штрафов, ибо новую работу не хуже они точно найдут — то тут не надо с пафосом рассуждать про «общую ответственность, общую цель, гимн компании хором распеваемый сотрудниками и проч бред» а надо менять свое отношения к людям.
                        Когда после внедрения какой либо фишки доход компании резко возрастет, люди реализовавшие эту фишку не получат прибавку к зп соразмерную с увеличившимся доходом (что логично и вполне ожидаемо), они получат просто зп, ибо договор тоже они подписывали на определенный оклад, так что и потери компании не должны никак сказываться на зп работников.
                          0
                          Так реализация фишки является обычной работой разработчика. С чего бы это как то выделять. Понятнее премировать того кто придумал фишку увеличившую доход, в том числе даже если это разработчик.
                            +1
                            > Понятнее премировать того кто придумал фишку
                            Прецеденты на вашей памяти были?
                            Вообще я понял одно, платить надо столько чтобы человек вообще не задумывался о премиях, леваках и проч.
                            И тот же Брукс вместе с Де Марко подтверждают что премии не всегда мотивируют положительно, особенно всякие ежеквартальные/ежечего то там — к ним человек быстро привыкает и относится точно так же как и к обычной зп
                              0
                              были, хотя у меня не очень большое количество работодателей для статистики.
                                0
                                а по поводу премий полностью соглашусь. идеальный вариант 13я зарплата как мне кажется :)
                                  0
                                  Интересно, а премия в виде опциона мотивировала бы лучше чем «обычная» премия*?
                                    0
                                    Зависит от многих факторов. Какой опцион, на каких условиях его дают (например увидев пунктик про аннулирование после увольнения я бы от такого опциона отказался — ибо сие больше смахивает на попытки привязать сотрудника к текущему месту)
                                    Еще в России часто практикуют выдачу кредита на «более лучших» условиях чем в банке для ключевых сотрудников, это уже совсем хомут на шее, такой сотрудник точно никуда не свалит по крайней мере на срок погашения кредита
                              –1
                              Уважаемые коллеги!

                              Ща подолью масла в огонь. Статью я писал долго, несколько дней. А комментарии горячие. Где-то могут оказаться неполиткорректными.

                              Я совсем не утверждаю, что за менеджемент в компании отвечают программисты. Я просто пытался объяснить, что если Вы видите недостатки, то, естетственно, о них сказать (а не ждать, что они исчезнут сами собой по мановению волшебной палочки) и этим помочь их исправить. Лучший вариант для ускоренного развития – это сотрудничество всех, кому не всё равно. Программисты совершают ошибки, но могут исправить их, если им на них указать. И менеджеры тоже совершают ошибки. И тоже могут их исправить, если им показать, где они не правы.

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

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

                              Что касается невыстроенных процессов, из-за которых Клиенту попал неоттестированный код, то любые процессы могут дать сбой, если участники нарушают технологию. Пусть выстроен совершенно правильный конвеер, но кто-то в цепочке недокручивает гайки. На выходе — брак. Любая технология состоит не только из набора процедур и правил, но и из решимости их выполнять. Нарушения способны похерить общий результат.

                              В описанном случае при обновлении у Клиента вылезла критическая проблема, которая не ловилась на тестовых данных. Её вынуждены были править на горячую. Стандартная технология осознанно нарушалась. Это могло бы пройти вполне нормально. У Клиента стоял бизнес, и он не готов был ждать официального выхода следующего релиза. Но, ЗАТО, готов был рискнуть. Надеясь, в том числе, на нашу сознательность.

                              В подобных случаях очень важно чувство личной ответственности, потому что оно, в значительной степени, компенсирует последствия нарушений правил выпуска. В критических случаях ваши коллеги имеют право рассчитывать на то, что вы делаете свою часть работы добросовестно. Я не вижу ничего военного в том, что вы разделите ответственность с другими за свою недоработку. В нашем случае наши сотрудники восприняли всё правильно – и я им за это благодарен. Они честно приняли отвественность на себя. И начали процесс планомерных улучшений, результатами которого я сегодня искренне впечатлён.
                              Ещё раз – штраф (огромная редкость и ЧП в нашей компании) был следствием откровенного нарушения правил. Это стоило многим людям бессонных ночей и больших переработок. Вы всерьёз полагаете, что наказаний за нарушения, приведшие к тяжким последствиям, быть не должно? Что можно отделаться словами о том, что виноват процесс, над которым нужно поработать всем?

                              Вот, например, водитель на дороге нарушил скоростной режим и сбил пешехода. Никаких инновационных методов регулирования скоростного режима не было применено, только знак «40» и «Осторожно — дети». Вы скажете, что нужно об общих процессах подумать, которые к этому привели, а виновника отпустить на восвояси? Нормально?

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

                              Как бы ни было в мире мало хороших разработчиков. Иначе их станет ещё меньше!

                              То, что хороших разработчиков мало, не оправдывает раздолбайства и безответственности. Конечно, вас мало и вы вольны вести себя так, как вам заблагорассудится. А я волен давать этому свою этическую оценку. Я, к счастью, знаю очень хороших разработчиков, которым не придёт в голову утверждать, что человек, который по их милости провёл вечер с их глючной прогой вместо того, чтобы повозиться со своей маленькой дочуркой, ДОЛЖЕН ЭТО СМИРЕННО ТЕРПЕТЬ, ПОТОМУ ЧТО ХОРОШИХ РАЗРАБОТЧИКОВ МАЛО.

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

                              Что касается примера работы в Штатах, то американские компании существуют в условиях, заметно более мягких, чем мы. Просто переносить систему отношений на наши условия не получится, поскольку наши условия много жёстче. Их Клиенты обычно платят им, самое малое, 250$ за час работы специалиста. Нам же пока платят впятеро меньше.

                              Зарплаты же у нас пониже. Но не в разы. А всего лишь на десятки процентов. Зато затраты на оборудование повыше, чем в Штатах. А накладные, вследствие необходимости взаимодействовать с отечественной бюрократией, больше. Доходы много меньше, расходы заметно больше. Вряд ли мы можем в лоб применять американские бизнес модели и модели внутренних взаимоотношений. Мы ухитряемся жить и расти в предельно трудных условиях (как лишайник на севере), постоянно заботясь об увеличении собственной эффективности. Задача для менеджмента – головоломная! Для нас потеря пары человеко-недель по причине индивидуальной безответственности – непозволительная роскошь.

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

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

                              Я, правда, даже не верю, что писавшие комменты искренне придерживаются этой позиции.

                              Друзья! Работа над ошибками, которая приводит к улучшениям — это улица с двухсторонним движением. Хотите работать в правильной эффективной компании – не молчите! Говорите, что вас не устраивает. Помогайте стать лучше!

                              Я – за открытую честную позицию. Не правильно полагать, что вот моё дело маленькое – просто писать код. А о том, чтобы он был достойного качества, должно позаботиться начальство. Пусть не жалеет денег на тестировщиков и выстраивает процессы.

                              Парень, ты – не прав! Качество твоего кода больше всего зависит от тебя.

                              У нас в офисе есть простой рабочий по имени Альберт. Этот человек просто не может делать свою работу плохо. Чем бы он не занимался, ремонтом унитаза или покраской двери, он всё делает максимально ответственно и качественно. Этот человек вызывает моё восхищение!

                              Я не могу понять, когда коллеги приводят аргументы, оправдывающие плохую работу!

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

                              Когда-то у Друкера прочёл объяснение того, почему сержант американской армии так сильно придирается к новобранцам на счёт пуговиц, воротничков, начищенных сапог, обслуженного оружия и т.д. Он приучает солдата к тому, что незначимых мелочей нет. Потом что в условиях боя любая мелочь может стоить солдату жизни!!!

                              Мы провели в компании внутреннее исследование (мы не сидели с секундомером – это был просто опрос). Так вот: устранение среднестатистической ошибки, обнаруженной самим программистом при самотетсировании займёт у него в среднем 20 минут. Общие затраты рабочего времени в компании, если ошибку обнаружит тестировщик, уже 2 часа. Если же ошибка всплыла у Клиента, то среднестатистические затраты времени на повторение, описание, исправление – 60 часов!
                              Казалось бы, вывод ясен – максимальные инвестиции в раннее обнаружение ошибок. Но во что инвестировать? У нас есть тестовые планы и сценарии нагрузочного тестирования. Каждую ночь мы запускаем автотесты, равные по объёму 10 человеко-месяцам ручного тестирования. Но всё это – лишь вспомогательные функции. Ничего из этого не заменит ответственного отношения программиста к тому, что он отдаёт пользователям.

                              Всё просто. Мне кажется, что здесь не с чем спорить. НО, поскольку, комменты на хабре меня радуют, я готов продолжить. 

                              Ещё раз на понимание. Я, прямо, вынужден оправдываться! За год штрафы были применены 1 раз и составили 5 % от месячной зарплаты.

                              Но коллеги! Вы действительно считаете, что не должны нести НИКАКОЙ ОТВЕТСТВЕННОСТИ?
                                0
                                Голосом мистера Маки «Систематические штрафы и поиски козла отпущения это плохо — п’нятненько»
                                Ну в вашем конкретном случае если это было «один раз» и мы не знаем всех подробностей кто у вас там и как накосячил — то тут судить ваш поступок дело неблагодарное.
                                Хорошие разработчики никогда не уйдут бросив на полпути все изза обидной фразы или штрафа (на то они и «хорошие»)
                                а вот те кто косячат постоянно и у которых код выглядит и работает плохо — это не «хорошие» это какие то неправильные разработчики. От таких либо избавляться — либо сажать в пару с хорошим и пусть экстримят пока не переучатся — ну а если не переучатся то опять таки увольнять.
                                Если же накосячил хороший разработчик (а такое бывает — все мы люди) то уж поверьте он сам будет себя чувствовать очень виноватым и не уйдет домой пока не поправит.
                                Вот это ответственность. Ну а боязнь получить штраф это не ответственность — это мотивация страхом.
                                Да большинство задач которые стоят перед разработчиком делаются почти на автомате, типа новая формочка, экшн для ее обработки, пару новых полей в базу и тп, такие задачи разработчик сделает быстро и без хлопот независимо от настроения. Ну а реально сложные задачи где надо проявить смекалку сделать что то неординарное — задачи где нужна очень большая концентрация умственных способностей — эти задачи разработчик над которым не висит дамоклов меч сделает намного быстрее и качественнее чем тот кто боится штрафа, увольнения и проч.
                                Вообще все капризы разработчиков идут не от того что «нас мало но мы в тельняжках», а от как бы пафосно это не звучало от «обстановки, от вида из окна, от шума вокруг», и еще множества факторов которые мешают «творить».

                              Only users with full accounts can post comments. Log in, please.