Нетехнические навыки для разработчиков. Зачем они нужны? Как развивать?

Некоторые специалисты активно продвигаются по карьерной лестнице и настолько приживаются в компаниях, что им платят любые деньги, лишь бы они не уходили. В чем их особенность? Может у них, при аналогичных технических навыках, есть какие-то врожденные способности, которых невозможно достичь? Или это какие-то навыки, которые все-таки можно в себе развить? Эти вопросы рассматривает руководитель направления 1С ресурсного центра Neti Андрей Макаров.

Одних технических навыков может не хватить

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

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

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

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

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

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

И первое, что мы сделали в компании – это попросили коллег и заказчиков описать, каким должен быть идеальный разработчик, какими навыками он должен обладать.

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

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

Мы подумали, что надо научиться как-то по-простому эту эмпатию у сотрудников развивать.

Чтобы это сделать, было придумано два вопроса, которые наши работники периодически должны себе задавать (или мы их сами сотрудникам задаем):

  • Что думают обо мне и о моих действиях коллеги, заказчики и все остальные люди, с которыми я взаимодействую?
  • Довольны ли они моей работой?

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

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

 

Первый контакт

Все начинается с первого контакта – это либо собеседование, либо разговор при приеме в команду. Тимлидер или архитектор общается с кандидатом и думает, брать его в команду или нет. На этом этапе очень важно создать доверие. Как мы обычно формируем доверие? Обычно, если мы знаем, что человек 10 раз что-то хорошо сделал, то мы верим, что и на 11-ый у него тоже все получится. Но при первой встрече этого не понять, поэтому изначально доверие надо создавать иначе.

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

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

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

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

  • Задавать вопросы. Это показывает, что вы услышали собеседника и задумались о его словах;
  • Во время разговора периодически говорить что-то типа «угу», возможно, с повторением каких-то особо важных фраз, но своими словами;
  • И в конце беседы нужно подвести итог, рассказать, что вы поняли, и что будете делать после этого разговора. Если подвести итог в виде действия, то это покажет, что вы не просто поняли, но и собираетесь использовать это в жизни.

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

 

Начало работы

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

Такая ситуация складывается из-за того, что люди боятся задавать вопросы. Это происходит по двум причинам:

  • Первая – человек боится, что его посчитают некомпетентным.
  • Вторая – человек боится, что ему скажут: «ты просто сам не хочешь думать».

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

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

У меня был один сотрудник, который делал печатную форму. В документе, из которого она брала данные, было несколько реквизитов – организация, сотрудник, сумма. И в печатной форме такие же реквизиты – все очень просто. И у него с заказчиком состоялась такая беседа:

Разработчик: «Что надо поставить в поле «Организация» печатной формы?» 

Заказчик: «Организацию!»

Разработчик: «А в поле «сотрудник»?»

Заказчик: «Сотрудника!»

Разработчик: «А в «сумму»?»

Заказчик: «Сумму!».

После такого диалога заказчик попросил поменять разработчика на кого-нибудь умнее.

Как потом оказалось, сотрудник все спрашивал по делу, потому что там была сильнодоработанная конфигурация, и реально могло оказаться, что «организация» – это не организация, а «сотрудник» – не сотрудник. Но формат, в котором он это доносил, был неверным. Если бы он спросил: «Правильно ли я понимаю, что «организация», «сумма» и «сотрудник» – это стандартные реквизиты из документа?», все было бы в порядке. Поэтому лучше показать, что вы уже подумали и теперь только уточняете.

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

По поводу того, как информация передается из головы в голову, могу порекомендовать книгу «Принцип пирамиды Минто».

 

Ожидания

Мы все чего-то ожидаем, но не всегда говорим об этом. Например, моя девушка (теперь уже жена) ожидала, что я женюсь на ней через несколько месяцев встреч. Но она об этом ничего не говорила, а я как нормальный чувак тупил 3 года. То же самое с заказчиками. Если вы понимаете, что какое-то ожидание не было озвучено, его надо выявить, озвучить и спросить – «А что здесь? У тебя есть какая-то дата, после которой эта задача уже будет не нужна? У тебя есть какой-то регламент, который нужно учитывать? У тебя есть какая-то стоимость, бюджет, за который выходить нельзя?». Хуже от этого точно не будет. Но будет точно хуже, если не спросите.

Если вы выявили какое-то ожидание, которое вы не сможете исполнить, объясните заказчику, почему это невозможно. Потому что когда человеку очень хочется, чтобы вы что-то сделали, а вы ему не сказали, что не сделаете, он будет считать, что «молчание – знак согласия», и сильно обидится, если вы не исполните то, что не отвергли.

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

Есть классная книга Скотта Беркуна «Осуществление задуманного». Она как раз рассказывает, как контролировать свои обещания.

 

Конфликт

Рано или поздно в компаниях возникают конфликты. В модели формирования группы, которую создал Брюс Такман, описаны три стадии – форминг, шторминг, перформинг.

  • Форминг – это стадия, когда люди знакомятся, пытаются максимально хорошо себя вести.
  • Шторминг – стадия, когда люди показывают, какие они есть на самом деле. Они начинают конфликтовать, притираться.
  • А перформинг – когда они договорились о чем-то, и их эффективность начала расти.

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

Например, к вам приходят и говорят, что у вас плохой код. Вряд ли кто-то сразу обрадуется такой обратной связи. Скорее, мы сначала испугаемся, а потом разозлимся. Испугаемся тому, что после 10 лет программирования наш код плохой – значит, жизнь не удалась. А разозлимся, потому что подумаем: «Да как он посмел, у него самого код плохой, да и сам он не очень!». И вряд ли эти мысли и слова помогут нам договориться. Скорее всего, мы начнем ругаться с собеседником и ни к чему не придем.

Но если мы попытаемся понять, откуда у нас появилась такая эмоция, то сможем это восприятие изменить (это называется рефрейминг). Потому что между ситуацией и эмоцией, которая возникла, всегда есть восприятие, интерпретация. Ситуация сама по себе ни черная, ни белая – она просто факт. Эмоции нам добавляет именно то, как мы ее воспринимаем.

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

Есть отличная книга, которую хочется порекомендовать, – «Эмоциональный интеллект. Российская практика», которая в простых русских терминах рассказывает, как вести себя в конфликтных ситуациях.

 

Зажатые эмоции

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

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

 

Обратная связь

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

Я всегда прошу своих сотрудников периодически (раз в неделю или месяц, в зависимости от проекта) задавать заказчикам такие вопросы:

  • Все ли устраивает в моей работе?
  • Могу ли я что-то улучшить?

Эти вопросы выполняют две задачи.

  • Первая – если что-то не так, вам об этом скажут;
  • Вторая – заказчикам будет понятно, что если что-то не так, с вами это можно будет решить. Потому что, если человек готов меняться, то ему пойдут навстречу и дадут второй шанс.

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

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

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

 

Переговоры

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

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

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

Здесь можно порекомендовать отличную книгу «Жесткие переговоры» Игоря Рызова. Она и про переговорщиков, и про интересы.

 

Клиентоориентированность – навык, который меняет все

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

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

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

Есть кстати, отличная книга, называется «Безупречный сервис» Ари Вайнцвейг. Она небольшая (читается за два часа), но очень хорошо рассказывает про клиентоориентированность. Мы сейчас компании выдаем ее для ознакомления всем новым сотрудникам.

 

Требования к сотрудникам

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

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

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

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

И последнее – навык удержания внимания. Почему-то в современном обществе люди очень тяжело фокусируются на одной вещи. Видимо, из-за того, что масс-медиа стали проще, появились какие-то волшебные рекламы, где все светится, горит, удерживает внимание. А у разработчика ничего не горит, ему надо в монитор смотреть и код писать. И как-то это сложно, мысли прыгают на другие проблемы и на разговоры вокруг. Эффективность падает. Поэтому внимание надо развивать. Оно развивается простой вещью – медитацией. Самое простое, что можно сделать — это по 10-14 минут в день сидеть и следить за дыханием. Тема на самом деле обширная, но в простом варианте примерно так. Когда вы медитируете, у вас развивается та область мозга, которая отвечает за внимание, именно за фокусировку.

Есть кстати интересная книжка Дэниела Гоулмана (он, в том числе, написал про эмоциональный интеллект) – называется «Фокус». Рекомендую.

 

Умение решать проблемы

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

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

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

Есть классная книга, которую могу порекомендовать в этом блоке – «Сила воли» Келли Макгонигала. Она рассказывает в том числе про физические особенности, влияющие на наши возможности выполнять разные дела и решать задачи.

 

Критическое мышление

Еще один полезный момент. Мир сейчас очень сильно меняется. Часто в компаниях бывают правила, которые уже не нужны, но «так принято». На эту тему есть интересный эксперимент. В клетку посадили группу макак, к потолку подвесили банан и поставили стремянку. Когда первая макака полезла наверх, всех облили холодной водой. Вторая лезет, всех опять обливают холодной водой. И макаки уже понимают логику, поэтому, когда за бананом лезет третья обезьяна, сородичи ее сбрасывают и начинают бить, чтобы показать, что не надо лезть за бананом, никто не хочет обливаний. Затем в клетку сажают новую макаку. Она тоже начинает лезть за бананом, и ее тоже спускают и начинают бить. Она не понимает, за что ее избили, но понимает принцип. Так заменяют по одной всех макак. И в какой-то момент в клетке уже не остается ни одной макаки, которую хотя бы раз обливали холодной водой, если она потянется за бананом. Но все равно все бьют то животное, которое поднимается по стремянке. Если бы макак можно было спросить, зачем вы это делаете, то они бы ответили, что тут так принято.

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

 

Желание развиваться

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

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

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

Поэтому обучать других людей – это на самом деле очень круто.

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

Одна из книг, которую я рекомендую в этом блоке, – «Искусство объяснять». Она рассказывает, как объяснять что-то другим людям. Авторы действительно системно подошли к этому вопросу.

 

Система развития сотрудников в нашей компании

Хотелось бы немного рассказать про культуру и систему развития на нашем примере, как мы все эти вышеперечисленные навыки пытаемся развивать и контролировать.

  • Когда к нам приходит кандидат, мы ему на собеседовании честно говорим, что у нас в компании надо постоянно развиваться, надо быть клиентоориентированным, заботиться о клиенте, о людях, о том, как вообще тебя воспринимает общество. Объясняем ему, что если у него есть какая-то проблема с вот этими «нетехническими» навыками, их надо «прокачивать». Обещаем ему обязательно давать обратную связь, главное, чтобы он был готов ей воспользоваться. Если человек согласен на все условия, то тогда он дал мне обещание, и мне потом намного проще будет с ним договариваться. Если просто навязать человеку все ценности компании, то он почувствует, что это не его. А если сам он принял для себя ответственное решение им следовать, то с ним уже можно работать.
  • Когда начинается работа, к новому сотруднику прикрепляют так называемого «тестового» заказчика, в качестве которого выступает наш более опытный коллега. И вот они взаимодействуют в течение определенного времени на какой-то специально подготовленной задаче с подводными камнями. И мы смотрим, как человек уточнил задачу в начале, как общался (первый контакт), как разговаривал, как объяснял «тестовому» заказчику, что происходит, как он оценивал задачу и контролировал сроки, как он сдавал и тестировал – весь процесс анализируем. Кроме того, постоянно спрашиваем у того человека, который является тестовым заказчиком – как ему работается с новым сотрудником, хочет ли он дальше с ним работать. И сразу даем обратную связь новому сотруднику. Если человек за этот промежуток времени не смог справиться с задачей, мы даем ему еще одну. Но если он дальше проваливает и проваливает задачи, то, скорее всего, тут все непросто и надо решать готовы ли мы его долго и упорно развивать без какой либо выручки. Если же сотрудник прошел «испытание», его можно подключать к проектам с реальными заказчиками. Потому что у него уже есть необходимый опыт.
  • Кроме этого, мы постоянно пропагандируем то, что важно для компании. Если кто-то обучился, сделал что-то грамотное, обрадовал заказчика, то мы об этом обязательно напишем во всех наших внутренних соцсетях, скайпах и чатах. Мы постоянно пропагандируем какие-то курсы, материалы, пишем какие-то общие письма. Я иногда пишу истории про то, какие навыки надо развивать, какие качества улучшать. Постоянный массированный поток информации по этой теме очень помогает людям. Если будет информационный вакуум, они не будут знать, что от них ждут. А так у них есть четкое понимание, куда стремиться. Плюс к этому мы периодически берем у заказчиков обратную связь по 10-бальной шкале по каждому из сотрудников, с которыми они работали. И вывешиваем общие рейтинги. И у людей появляется желание как-то себя улучшить.
  • Еще одна вещь – внутренние тренинги по нетехническим навыкам. Мы их делаем, но хочется чаще и больше. И чтобы в итоге получился готовый курс, который будет проходить каждый новичок перед началом работы. Это долгий процесс, но как он будет завершен, мы планируем выложить это в общий доступ.

****************

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2024 COMMUNITY. Больше статей можно прочитать здесь.

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

Выбрать мероприятие.

42 Comments

  1. mrm1212

    Отличная статья! спасибо!

    Reply
  2. gradi

    Однозначно в избранное. Спасибо.

    Reply
  3. taishy

    Автор почему-то не учитывает такой критерий личности как интроверсия-экстроверсия. И, что большинство программистов все-таки интроверты…

    Reply
  4. DarkUser

    Зачем такие требования к разработчикам? С разработчиком должен общаться один, максимум два человека — руководитель проекта и аналитик. Клиенты вообще не должны знать контактов разработчика и тем более общаться с ним.

    Reply
  5. Boneman

    (4)

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

    очень спорное утверждение

    Reply
  6. OlegTor

    Андрей, большое спасибо за материал! Особенно понравились примеры из вашего личного опыта, а также список рекомендованных книг.

    Reply
  7. boln
    Зачем такие требования к разработчикам? С разработчиком должен общаться один, максимум два человека — руководитель проекта и аналитик. Клиенты вообще не должны знать контактов разработчика и тем более общаться с ним.
    очень спорное утверждение

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

    Reply
  8. dock

    Супер! А какое пополнение библиотеки!

    Reply
  9. Boneman

    (7)

    А за проект отвечают руководитель и аналитик, и это их вызовут на ковер, а не разработчика.

    если под разработчиком понимать, (человек который тупо копает то-что его заставили копать), то да. Хотя, даже при этом раскладе, скорее всего крайним будет, тот, кто копал. Ибо окажется что он выкопал не такую яму, какую было надо.

    В жизни, такого почти не бывает.

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

    З.Ы. Естественно, что если в проекте работает несколько разработчиков, то они не все принимают участие, а должен быть главный.

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

    Хотя, каждый имеет право на свое мнение. ))))

    Reply
  10. Kutuzov

    (4) Ваше замечание относится, наверное, к крупным проектам — на 1000 рабочих мест и больше, там можно выделить отдельного специалиста-аналитика, и исключить разработчика из проработки бизнес-логики. В проектах по-мельче, на ~100 рабочих мест, как правило разработчик и аналитик совмещены)

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

    Reply
  11. байт

    Статья хорошая, вот только бы еще описание как работать с трудными клиентами)

    Reply
  12. herfis

    Замечательная статья. Очень редко попадается настолько качественный вводный материал.

    Reply
  13. Infector

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

    Reply
  14. herfis

    (4)(13) А ничего, что в статье речь преимущественно о нормальных общечеловеческих качествах, которые неплохо бы заиметь всем и каждому? 🙂

    Или «нормальность» нынче удел отдельных людей, на ней специализирующихся? 🙂

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

    Reply
  15. acanta

    (11) Устроиться к ним в штат и породниться.

    Reply
  16. nofear

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

    Reply
  17. Neti

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

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

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

    Reply
  18. andmakarov

    (17) Это мой комментарий 🙂 Под логином компании нечаянно выложил 🙂

    Reply
  19. qwinter

    (10) его замечание неверно для любых проектов. Системные архитекторы существуют не просто так, для красоты.

    Reply
  20. Infector

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

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

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

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

    Reply
  21. acanta

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

    Но при этом он должен быть полностью взаимозаменяем.

    Reply
  22. байт

    (21) Не ты ли это?))

    Reply
  23. MikhailDr

    (21)

    Но при этом он должен быть полностью взаимозаменяем.

    Один человек не может быть «взаимозаменяем», это должна быть как минимум пара людей

    Reply
  24. CSiER

    Спасибо за статью и за список литературы.

    И последнее – навык удержания внимания. Почему-то в современном обществе люди очень тяжело фокусируются на одной вещи.

    — по данной теме в контексте работы программиста мне очень понравилась книга (В работу с головой. Паттерны успеха от IT-специалиста) — рекомендую.

    Система развития сотрудников в нашей компании

    — данная статья про нетехнические навыки — есть ли / планируете написать статью про технические навыки?

    Reply
  25. acanta

    (22) Послушать некоторых 1с ников, ни дать, ни взять олигархи. 2 молзавода, птицефабрики, хлебозавод, пара сельхозпредприятий, сеть общепита и пара гостиниц. А собеседования в фирму франчайзи это вообще шоу «Выйду замуж за миллионера».

    Reply
  26. MaxS

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

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

    Reply
  27. acanta

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

    Reply
  28. acanta

    (20)

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

    Ну какая тут подмена, 1C — это любовь, что без денег делает тебя богатым (с)

    Reply
  29. Armando

    Я один считаю, что за фразу «Правильно ли я понимаю, что» надо расстреливать?

    Reply
  30. herfis

    (29) А что с ней не так? Если аллергия именно на это вступление, можно и перефразировать.

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

    Reply
  31. Armando

    (30) Да, именно эта фраза раздражает из-за ее массового использования. С важностью устранения недопонимания полностью согласен.

    Reply
  32. herfis

    (31) Ну, несколько рафинировано звучит, но для первого контакта нормально, как по мне 🙂 Первый контакт предполагает некоторую настороженность и дистанцирование.

    Reply
  33. andmakarov

    (24)

    конте

    Спасибо за рекомендацию книги!

    По технические навыки пока не планировал. Но возможно передумаю. Спасибо за идею.

    Reply
  34. andmakarov

    (11) Ок. Как-нибудь напишу 🙂

    Reply
  35. orfos

    В статье очень много приемов которые можно использовать не только в своей работе, но и в повседневной жизни. Здорово! Мне понравилось про — «периодически делайте то, что для вас нестандартно». Сначала нестандартное обучение, а потом пригождается на практике.

    Reply
  36. acanta

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

    Reply
  37. tramontana

    «Искусство объяснять» кто авторы?

    Reply
  38. elian

    (4) Это возможно только в том случае, когда у разработчика есть аналитик. Но так бывает далеко не всегда.

    Reply
  39. andmakarov

    (37)

    Искусство объяснять

    Ли ЛеФевер

    https://www.mann-ivanov-ferber.ru/books/paperbook/art-explanation/

    Reply
  40. andmakarov

    (37)

    Ли ЛеФевер

    Reply
  41. YuriFm

    Про мотивацию:

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

    Не пойдет, больший объем работ выполнит.

    Reply
  42. acanta

    (41) На работе одинокие люди скрываются от пустых комнат и скучных вечеров, а счастливые семейные — они тоже скрываются от семьи, детей, хлопот и прочих «радостей». Им не важен объем работ. Им все равно что делать, у них мозг «убегает и прячется в работу»/голову в песок.

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

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

    К сожалению, «убегающие» не приемлют мотивы «догоняющих» экзистенциально. «Хотелки» воспринимаются в штыки. Я же сижу и работаю на том что есть! И ты тоже должен. А не бегать с костылем за кем-попало.

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

    А так , «Убегающий» автоматизатор это катастрофа.

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *