Перевод статьи Спиро Флоропоулоса «How developers and employers can maintain peace».
В двух моих последних статьях (здесь и здесь) я поделился опытом из своего прошлого, освещая вещи, которые не стоит делать работодателю и разработчику. Я рассматривал эти аспекты как элементы «холодной войны», которую эти две группы людей ведут друг с другом.
В данной статье я хотел бы уделить внимание советам в положительном ключе. Я по-прежнему надеюсь, что люди из обеих частей сообщества смогут чему-нибудь научиться.
Уважайте время друг друга
Я думаю, это самая ценная рекомендация. Уважение времени касается обеих сторон и может оказаться бесценным.
Для работодателей это может означать, что они изо всех сил стараются придерживаться разумных требований и избегать расширения границ этих требований. Это может означать постановку как можно более реалистичных дедлайнов. Это также и отсутствие слишком больших запросов к разработчикам в плане их времени в любой день, неделю или месяц.
Для разработчиков это может означать отсутствие избыточных инженерных решений. Это может означать отведение для своей общественной жизни должного времени вне рабочих часов. Это может означить честность в отношении оценки необходимого на разработку времени.
Помогайте друг другу учиться
Мне кажется, это тоже очень важный фактор, поскольку тоже работает в обе стороны.
Для работодателей это может означать очень четкое и понятное выражение бизнес-требований к задаче и пояснение последствий ее выполнения/невыполнения для бизнеса. Это также и объяснение работы определенных аспектов бизнеса за пределами технологического стека. Это предоставление разработчику(-ам) возможность использовать или выполнять что-то, отличающееся от первоначальных намерений.
Для разработчиков это может означать обучение тому, как уважительно учитывать требования бизнеса в проекте. Это помощь работодателю в понимании какого-нибудь технического аспекта. Это честность в отношении временных рамок или технического долга, а также в отношении того, почему это может стать проблемой.
Будьте опорой друг для друга
Этот пункт более общий, поскольку включает в себя и рекомендации всей статьи. Но на ум приходит и кое-что специфичное.
Для работодателей это могло бы быть что-то простое, вроде отдание должного разработчику, который хорошо выполнил свою работу, уложился в сроки и бюджет. Честно говоря, это просто сообщение разработчику (или любому другому работнику), что он на верном пути. Программисты могут быть беззащитными, даже если у них большое эго, так что несколько заслуженных добрых слов имеют большое значение. Так вы помогаете разработчику почувствовать себя успешным, а это поощряет его к дальнейшему продвижению.
Что касается разработчиков, вы можете задуматься о том, какую обратную связь вы даете работодателю. Когда вы в последний раз его благодарили за оплаченную вам крутую работу? У меня есть пара рабочих отношений, которые с годами превратились в дружеские, но для этого понадобился хороший уровень коммуникации. Я не мог бы рассчитывать услышать «Хорошая работа!», если бы не говорил «Мне нравится работать здесь» или «Это был такой классный проект! Дайте еще!».
На самом деле не будьте безразличны друг другу на личном уровне
Это продолжение предыдущей темы.
Социальные отношения, по моему мнению, это искусство. Я по природе интроверт, и общение мне нелегко дается. Мне приходится бороться с собой, чтобы победить свои ощущения.
Не важно, разработчик вы или работодатель, – покажите какой-то интерес друг к другу. Для меня темой для разговоров зачастую является мой ребенок. Если вам тяжело запоминать, о чем вы говорите с окружающими, – записывайте.
Сложно заметить, что ваша социальная активность и программирование имеют равное значение, но я гарантирую, что они взаимосвязаны. Когда вы чувствуете связь с людьми, с которыми работаете, разница огромна.
Уважайте знания и опыт друг друга
Это достаточно легко и просто.
Предположим, вы работодатель. Если бы вы могли сами создать сайт или систему, о которой попросили разработчика, вы бы сами его и создали. Вряд ли вы вообще обращались бы к разработчику. Это как попросить строителей построить вам дом, а затем, будучи фармацевтом, приходить и рассказывать им, как именно они должны строить. Ваш разработчик обладает определенными знаниями. У него есть навыки и опыт, каких, вероятно, у вас нет. Уважайте это и доверяйте ему.
Если вы разработчик, вы тоже должны быть к этому готовым. Вам нужно быть честным в отношении границ своего опыта. Забудьте о своем эго. Не будьте всезнайкой. Сказать, что не знаете, как подойти к какой-то проблеме, целиком нормально. Более того, очень полезно погрузиться в бизнес, с которым вы имеете дело, и понять его. Это имеет большое значение для проектирования и выполнения вашего собственного кода.
Бросайте вызов друг другу
Да! Это нормально! Нормально обсуждать подходы. Нормально даже спорить. Нормально стоять на своем или уступать, если приведены веские доводы.
Когда вы бросаете друг другу вызов и аргументируете свою позицию, вы не чувствуете, что вы ссоритесь. Это может быть стоящим процессом, в ходе которого обе стороны многому научатся.
У меня именно так происходит с моим другом, с которым я часто работаю. Он относится к категории собственников продуктов, а я разработчик. Иногда мы спорим о вещах, имеющих отношение к пользовательскому опыту или к SEO. У меня один подход к делу, а у него другой. Только от нас зависит, убедим ли мы друг друга. Подумайте об этом.
Речь об убеждении.
Дело не в том, чтобы показать, кто здесь умнее или что-то вроде того.
Вы хотите, чтобы кто-то принял вашу сторону и осознал ее преимущества. Конечно, это означает, что вам нужно быть достаточно открытым, чтобы тоже суметь встать на сторону другого!
Коммуникация должна быть такой, будто от нее зависит ваша жизнь
Это очень важно и для удаленно работающих команд.
Однажды я руководил командой в 12 человек. Один из них был в Австралии. Он выходил на связь каждые 2-3 часа. Аккуратно, как часы. Даже чтобы просто сказать «С последнего раза никаких изменений». Поначалу количество сообщений, которые приходилось читать, раздражало.
Но я быстро, очень быстро изменил свое мнение на этот счет, когда у меня появился другой член команды. Он не говорил со мной в течение дня, а потом, в конце дня показывал мне, что сделано, и оказывалось, что он отклонился от курса. Я бы предпочел, чтобы меня пинговали каждые три часа и я был бы в курсе дел, вместо того чтобы иметь восемь часов неизвестности и сомнений в результатах.
Работодателей это тоже касается. Коммуникация может состоять в объяснении требований или того, почему у вас именно такой временной отрезок, или подобных вещей. Когда речь заходит о коммуникации, исходящей от работодателя, подход немного отличается, но это все равно важно. Чтобы разработчики могли предоставить вам правильные ответы, вы должны суметь помочь им понять ваши потребности.
Заключение
В целом, это лишь несколько вещей, которые я выбрал, исходя из своего опыта. Надеюсь, это поможет кому-нибудь еще. Если у вас есть свои мысли на этот счет, поделитесь ими в комментариях!
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]
