Посещая программерские форумы, я постоянно сталкиваюсь с тем, что люди обсуждают организацию дел в компаниях, где они работают. Причём часто в очень обиженных тонах.
Более того, я и сам, бывало, я вдруг, совершенно неожиданно получал письмо от хорошего грамотного разработчика, о серьёзных управленческих ошибках руководства, которые подрывают мотивацию команды и её веру в светлое будущее. В письме обычно давался разбор какой-нибудь цепочки ситуаций, а затем сообщалось о том, что автор устал и не видит для себя больше возможности работать в компании. Я не наивен и понимаю, что, скорее всего, разработчик увидел где-то в другом месте, например, более заманчивые финансовые перспективы. Однако, не стоит упрощать – иногда люди переходят в другую компанию на ровно такую же зарплату, а бывало (и к нам и от нас) даже и с потерей.
Уход разработчика всегда не только крайне огорчителен, поскольку команда теряет ценного сотрудника. Уход может быть критичен, поскольку Компания уже взяла на себя обязательства в расчёте на данного сотрудника и невыполнение этих обязательств грозит Компании различными бедами вплоть до невозможности выплатить вовремя зарплату большому числу ни в чём не повинных товарищей.
Обнаружив, что разработчики часто довольно туманно представляют себе, как устроены «глобальные» бизнес процессы в компании, я решил попробовать объяснить разработчикам, с какими проблемами сталкиваются те, кто пытается организовать их труд и направить его в «мирное русло».
Управляя какой-нибудь структурой, менеджерам приходится принимать множество разных решений, которые меняют и саму структуру и процессы происходящие в ней. Это очень похоже на программирование. Допустим, возникла необходимость ускорить работу программы – этого требует Клиент, иначе он её не купит. Вы начинаете думать, как вам этого достичь. У вас есть идеи, чтобы их проверить, вам нужно внести изменения в код – и когда вы делаете это, вы принимаете управленческие решения. Ровно то же самое делает и менеджер – он вносит изменения в код, в алгоритмы взаимодействия частей управляемой системы, то есть сотрудников. Правда система много сложнее программы, поскольку в ней есть ещё такие факторы, как психология, эмоции, чувство справедливости и многое другое.
Не все решения оказываются удачными. Ровно, как и у программиста. Некоторые изменения в коде в определённых случаях приводят к ухудшению работы программы, а иногда и к её краху. Правда, в отличие от менеджера, программист может сам множество раз запускать свою программу и смотреть, что получается, как она работает. Но даже в этих случаях, как показывает наша с вами практика, код может содержать множество важных и даже критических ошибок. Что происходит дальше. Ваш код тщательно тестируют тестировщики, другие специалисты (внедренцы, руководители проектов и т.д.) и сообщают вам о найденных дефектах, что даёт вам возможность их поправить.
Но и после этого у Клиента могут всплыть новые ошибки. Он сообщает о них. Тестировщики их локализуют – и к программисту поступает следующая информация: в таком-то месте программы имеется такая-то ошибка, которая приводит к таким-то неприятным последствиям.
Теперь представьте себе, что об обнаруженных в вашем коде ошибках все молчат, ничего вам не сообщают. Но зато обижаются на всё новые и новые ошибки, рассуждая следующим образом:
«Ну что такое? Этот парень совершает всё новые и новые ошибки! Как можно отдавать нам ПО с этими багами? Просто поток ошибок! Да он нас совсем не уважает! Наша мотивация от работы с ним опускается всё ниже и ниже…».
Наконец принимается решение «Это терпеть больше нельзя! Мы больше не хотим с ним работать!»
Как вы думаете, правильно ли так поступать по отношению к программисту? Получится ли у него хороший код без обратной связи об ошибках и необходимости тех или иных улучшений? Есть ли перспектива добиться хорошего результата при таком подходе? Думаю, что ответ – очевиден.
Но менеджер оказывается именно в такой ситуации. Он, как и программист, совершает различные ошибки, но потребители его управленческого кода, его подчинённые чаще всего упорно молчат и обижаются, обижаются и молчат. А потом заявляют об увольнении.
Нормально ли было бы, если бы Клиент сначала долго терпел ошибки в нашем ПО, ничего о них не сообщая, а затем, в конце концов просто послал нас, потому что такие ошибки просто невозможно больше терпеть!
Я думаю, ненормально. Правильная ситуация – это сотрудничество с Клиентом, который указывает нам на наши баги, делает свои предложения о том, как улучшить ситуацию – и тогда совместными усилиями мы получаем достойный продукт, который у нас сейчас приобретают ведущие мировые компании.
Ровно то же касается и менеджмента. Следуя потребностям наших Клиентов, мы в стремлении к улучшениям вынуждены менять нашу компанию, принимать различные управленческие решения, вносить изме6нения в её код. Иногда мы совершаем ошибки. Программисты знают, можно написать тысячу строк правильного кода и ещё пару строк, которые сделают неработоспособной всю программу – и то, что написано сейчас, и то, что написано раньше, вами самими и другими людьми до вас. Рецепт борьбы с этой неизбежной неприятностью прост: обнаружение ошибки, информирование о ней, локализация, исправление.
Ровно то же касается и управления. Менеджеры, как и программисты, всегда будут совершать ошибки. Но благодаря обратной связи они смогут их исправлять. И вместе с подчинёнными делать систему всё более эффективной, которая сможет работать всё лучше и зарабатывать всё больше.
Не смотря на всегдашний шок и огромное искреннее огорчение, я уже почти привык к недоразумениям, описанным мною в
начале письма (потому что они случались со мною десятки раз). Но меня всегда изумляет наивная вера программистов — людей, имеющих реальный опыт создания сложных систем — что в управлении все должно было правильно, а ошибки менеджеры совершать не должны. А если реальность в Компании не такова, то они обижаются (ну, или у них падает мотивация – как хотите назовите).
То есть, Клиент не говорит: «Ребята, здесь у вас ошибка, поправьте, пожалуйста», а молчит и всё больше обижается за неправильное отношение к его нуждам и чаяниям. Он считает несправедливым, что ему отдают код с ошибками, а потом у реально тысячи человек мучаются. А справедливым он считает — назвать это свинством с нашей стороны.
Представьте, когда у нас Клиент — правильный, мы, совместными усилиями, пройдя через определённые трудности, всё равно, в конце концов, можем создать действительно отличную систему, которая будет всё больше и больше отвечать его потребностям, с которой ему будет всё более и более комфортно.
И совершенно невероятно, что Клиент получит то, что ему нужно, то, что для него комфортно, если он будет молча обижаться. Да хоть мы все на пупе извертимся, а результат хорошим не будет, потому что мы из-за незнания и непонимания будем совершать всё новые и новые ошибки, а ситуация будет всё хуже и хуже.
Это я пишу к тому, что мы сами – кузнецы своего счастья. Мы сможем эффективно двигаться в правильном направлении, к тому, чтобы все в разработке были довольны и счастливы, если у нас будет обратная связь, и мы будем вместе работать над улучшением нашей системы — нашей компании.
От Клиента нам нужна оплата наших услуг в обмен на удовлетворённость его нашим продуктом.
От Разработчика нам нужен эффективный труд в обмен на удовлетворённость его работой в нашей компании.
Клиент, в идеале, хотел бы, чтобы мы работали за 20000 рублей в месяц и сразу выдавали то, что ему нужно, желательно не через год, а через пару недель, и чтобы сразу всё работало идеально и без ошибок, и без дурацких вопросов, как ему лучше — так или так («Неужели Вы сами не знаете, чего я хочу? Вы же называете себя специалистами!»)?
Мы с вами понимаем, что это невозможно. Мы не станем работать за 20000 рублей в месяц. Многие вещи даже гений не сделает за пару недель, поскольку на эту работу нужно полгода команде из трёх человек, если повезёт и не всплывут неизвестные трудности. Программы же работают так, как нужно только после нескольких итераций, исправления многих ошибок и внесения множества предложенных Клиентом дополнительных улучшений. Но осознав, что за хороший конечный результат мы отвечаем оба – и Исполнитель, и Заказчик, что этот результат возможен только, как плод совместных усилий и компромиссов, правильный Клиент получает, в конце концов, то, что ему нужно, то, что обеспечивает ему конкурентное преимущество перед соперниками.
Программист в идеале хотел бы, чтобы ему платили тысяч 150 рублей, при этом никогда не было переработок, он мог бы заниматься не тем, что нужно Компании, а тем, что ему интересно. И желательно, чтобы штрафы, которые иногда бывает вынуждена платить компания за критические ошибки в его коде, его не касались вообще никак. Компания, у которой в результате его косяков стало на 300 тысяч рублей меньше на закупку нового оборудования, мебели и т.д., должна просто объяснить команде проекта, которая получает ЗП много меньшую, чем программисты, но зато получает премию от дохода проекта, что они теперь получат на всех на 100 тысяч рублей вознаграждения меньше. Но программистов, которые отдали Клиенту вообще никак не оттестированный код, нельзя оштрафовать даже на пару сотен, то есть на процент от потерь компании, потому что им так некомфортно – они бы хотели, чтобы ответственность — финансовую, даже символическую по сравнению с потерями других, программисты не несли в любом случае (как говорится, «штрафы разработчиков демотивируют»).
Мы понимаем, что это невозможно. Невозможно получать большее вознаграждение, ничем не жертвуя ради этого, не став лучше, не пройдя трудный путь к совершенству, к тому состоянию, когда Клиенты реально согласны платить много, потому что мы, как компания, того стоим. Для этого нам нужна репутация, которую мы постепенно и трудно завоёвываем и которую легко потерять после нескольких залётов.
Невозможно всегда избегать ответственности за промахи. Если многие люди в компании реально пострадали и в моральном плане (Клиент, с которым они общаются постоянно и от которого зависит успех их работы, считает, что его грубо подставили, потому что он простоял целый день и каждый из 200 агентов и пары десятков супервайзеров недозаработал в этом месяце по 5% своей зарплаты, а владелец 10% своей прибыли — и все на них злы), и в материальном плане: доход проекта стал заметно меньше – и их вознаграждение стало заметно меньше. Команде проекта (это много людей), которая честно трудилась и на которую обиженный Клиент водрузил и моральную и материальную ответственность, невозможно объяснить, почему за этот косяк, к которому они не имеют прямого отношения, должны отвечать только они и совсем не должен отвечать тот, кто его допустил. Заметьте, речь не идёт о том, что код должен быть безбаговым – речь идёт о том, что он попал Клиенту вообще без тестирования.
В этой ситуации менеджер уже даже и не может принимать любые решения. Справедливости у него требуют десятки пострадавших, которые страшно обидятся на Компанию уже совсем бесповоротно, если реальные виновники их бед хотя бы не разделят с ними реальную, то есть финансовую ответственность.
Но если программист, так же как и Клиент в его случае, не будет ждать чуда, не будет надеяться, что ему какие-то дяди-менеджеры организуют всё так, что за одну и ту же работу, за которую он не хочет нести существенной ответственности, он почему-то со временем будет получать всё больше и больше, а, напротив, будет указывать менеджерам на их ошибки, помогать локализовать проблему, подсказывать своё видение решения, то мы, как и в случае итерационного создания ПО, будем итерационно улучшать нашу организацию, нашу ответственность и наши методы мотивации. Мы нарастим и укрепим с таким трудом завоёванное нами сегодняшнее лидерство. И Клиенты будут платить нам больше и охотнее. И ЗП программистов будет реально расти, потому что эффективность их будет расти. Не только благодаря росту индивидуального мастерства, Но и благодаря более правильной, более рациональной организации нашей работы. Ведь наилучшая стратегия для роста зарплаты – это рост эффективности и качества.
Есть такой известный пример, иллюстрирующий положение лидера. На чемпионате по гольфу призовой фонд для победителя составляет один миллион четыреста тысяч долларов, занявшему второе место выплачивают шестьдесят тысяч, а третьему только двенадцать тысяч. При этом результат первого всего лишь на полпроцента лучше второго, и на полтора процента лучше третьего. Ровно те же правила действуют в бизнесе. Лидер, который на пару процентов лучше второго, получает во много раз большее вознаграждения. Нужно стремиться быть первым – и награда не заставит себя ждать. Мы делаем очень сложный бизнес, в котором все сильно зависят друг от друга. Может 40 человек очень стараться и работать много и честно, а неправильные действия одного испортить труд многих. Помните пословицу про ложку дёгтя в бочке мёда? Мы живём в 21-м веке и не очень понимаем, что такое дёготь. Предлагаю более понятно. В целой бочке повидла маленькая чайная ложка дерьма. Вряд ли вы, зная об этом, захотите это есть. Результат работы конкретного программиста может драматически влиять на результат работы всей команды разработчиков, внедренцев, менеджеров. Было бы здорово, чтобы мы совместно нашли способ повышения индивидуальной ответственности разработчиков, поскольку от этой индивидуальной ответственности зависит иногда множество людей. Представьте, что на автомобильном конвейере на одном из участков по сборке двигателей втулку цилиндра устанавливают с нарушениями технологии. Этот косяк обесценивает честную работу всех остальных участников процесса, потому что, независимо от старательной работы всех остальных, на выходе получается брак.
Правильный путь с моей точки зрения – не требовать освобождения от ответственности. Потому что она, всё равно, наступает и от неё освободить нельзя – можно только переложить её на других. Помните «Наказание невиновных, награждение непричастных»? Это же неправильная, гибельная стратегия! Нужно так организоваться, чтобы эта ответственность не наступала, потому что всё у нас – реально хорошо.
Условия, в которых мы существуем – объективны. И менеджеры ошибаются, точно так же, как и программисты, из лучших побуждений, из желания сделать систему лучше, дополнить её фичами, улучшить быстродействие, срезать углы в логике. Только через исправление управленческих ошибок можно сделать нашу систему лучше, а нашу жизнь интереснее и комфортнее.
Ещё пара аналогий программирования с управлением. То, что решения часто нуждаются в корректировке так же, как и программный код, и то, что для этого нужна обратная связь от потребителей управленческих решений, то есть, от сотрудников, нам, думаю, уже понятно.
У Клиентов иногда обнаруживается какая-нибудь серьёзная ошибка/проблема, которая не может быть поправлена влёт. Иногда, для того, чтобы ошибку/проблему разрешить нужны серьёзные усилия и много времени, поскольку бывает, что нужно, как в анекдоте «всю систему менять». Неумный Клиент иногда не понимает: «Я сообщил вам о проблеме уже 3 недели назад, а она до сих пор не исправлена! Вы ничего не делаете!». Он иногда не может уразуметь, что у нас есть очередь из задач на разработку, и мы не можем решать сразу все проблемы одновременно. Что проблема сложна и требует много человекомесяцев и внесения изменений в целый ряд взаимозависимых подсистем. Если он наберётся терпения, то, в конце концов, получит то, что ему нужно. И его система будет лучше, чем у конкурентов, потому что он помог нам сделать её лучше, чем у конкурентов. Вряд ли результат будет хорошим, если Клиент занимает позицию: «Я – Клиент и поэтому всегда прав. Не грузите меня Вашими проблемами – просто сделайте, чтобы я был доволен». Если Клиент для Вас – это слишком далеко (жаль, если это – так), то представьте на его месте тестировщика, который ничего не объясняет, на ошибки не указывает, просто требует, чтобы Вы сделали так, чтобы он был доволен. И притом прямо к следующей среде. Скажите, есть нормальные конструктивные перспективы у этой ситуации?
Вот и у нас, даже если сотрудники не молчат, этого не достаточно для решения всех проблем. Многие сотрудники и вправду искренне заинтересованы в улучшениях и дают менеджерам обратную связь о проблемах. Она — очень полезна и заставляет менеджеров осознать эти проблемы и искать их решение. Но я часто слышу следующее – «мы уже говорили об этой проблеме в мае, но воз и ныне там – в этой компании ничего не происходит» (читай: «и поэтому наша мотивация неуклонно опускается»)!
А разве мы сами не говорим Клиенту, что вот эту его проблему невозможно решить за две недели – нужны упорные и ДОЛГИЕ усилия целой команды. А иногда даже (какой кошмар!) мы осознаём проблему, но пока не придумали, как с ней справиться. Но обязательно придумаем (ещё не было так, чтобы мы, в конце концов, не решили поставленных перед собой задач!). Нужно помогать искать выход, и нужно быть терпеливым. Терпение – это добродетель, которая в правильном месте вознаграждается.
Два года назад в компании работали 70 человек. А сейчас в ней работает 250 человек. Все эти люди сильно зависят от работы программистов, то есть от вас. Им, для того, чтобы не вздрагивать по ночам, необходимо быть уверенным, что те, от кого они так сильно зависят – люди спокойные, рассудительные и ответственные. И не скажут в любой момент, вы — как хотите, а я – пошёл… Вот вам моё заявление об уходе. Обещания, которые Вы надавали в расчёте на меня, меня не волнуют. Что будет с коллегами, которые эти обещания подтверждали лично в глаза Клиентам, мне всё равно. Мне с ними детей не крестить.
Когда так, к сожалению, всё-таки происходит, руководству приходится учитывать не только интересы того, кто собрался уходить, но и интересы тех двух с половиной сотен людей, которые остаются и которые никому ничего плохого не сделали, чтобы вот так запросто пострадать. Поэтому мы стараемся объяснить в таком случае, что нам очень поможет, если они отработают хотя бы месяц, а мы сможем как-то сориентироваться и передоговориться с Клиентами. У желающих уволиться есть права, но грош была бы цена нашим менеджерам, если бы они не отстаивали так же права тех, кто остаётся.
Мы всегда с огромным уважением относимся к кандидатам, которые говорят: «Я хочу у вас работать, но у меня есть обязательства по старому месту и я должен их закрыть. Вы можете подождать?». Ответственность – очень важное качество, и мы всегда говорим: «Конечно. Мы потерпим. Закрывайте свои долги». Мы хотели бы, чтобы к нашим нуждам относились так же ответственно, как мы относимся к чужим. Своей просьбой отработать месяц-два вместо двух недель мы удерживаем ребят от неправильного поступка, за который потом (когда повзрослеют) им было бы стыдно.
Ещё раз повторю: Наша компания, наша организационная структура, наши процессы – это код, который мы пишем вместе. Давайте нам обратную связь, идеи об улучшениях, помогайте их воплощать – и мы будем гордиться своей компанией, потому что в ней будет работать комфортно и интересно.
Автор: SMaksimenko
