Отказ от ответственности: ни в коем случае разработчики не пострадали в процессе исследования этой статьи.

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

 

Мой собственный набег на развитие

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

 

Требования разработчика

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

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

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

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

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

 

Мотивы разработчика

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

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

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

Другие мотивы включают:

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

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

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

 

Взаимодействие с видами

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

 

Предоставление и получение совета

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

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

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

Точно так же разработчики могут настаивать на определенных решениях, которые невозможно реализовать с точки зрения эксплуатации или общедоступности. У вас есть решение для автоматизации 75% заданий, но оно обеспечивает точность только 81%? Что ж, это может быть техническое чудо, но это просто не сработает с точки зрения бизнеса и обслуживания клиентов. Не говоря уже о кошмаре по связям с общественностью увольнения трех четвертей сотрудников. По этой аналогии вы бы не хотели, чтобы ваш кардиохирург ремонтировал вашу разрывную трубу в экстренной ситуации, если он никогда раньше не испытывал чрезвычайных ситуаций с давлением воды 80 PSI.

 

Управление ожиданиями

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

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

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

 

Продвижение и обязанности

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

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

 

Время в одиночестве и общение

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

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

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

 

Вопрос о сроках

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

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

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

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

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

 

Заключительные замечания

Как и любая хорошая (не) научная статья, мы хотим закончить кратким изложением и заключением.

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

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

 

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

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

И все в офисе, а не только разработчики программного обеспечения, вроде как делают это все время (глядя на компьютеры)