Как я создаю команды разработчиков мирового уровня

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

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

Я также должен отметить, что эти значения не были предоставлены моим нынешним или бывшим местом работы. Эти ценности мои, а не корпоративный постер, безжизненно висящий на стене рядом с кошачьим плакатом «держись».

Психологическая безопасность

Рабочее место должно быть убежищем безопасности — средой, в которой вы чувствуете себя в безопасности независимо от расы, религии или любимого сериала «Звездный путь». (Правильный ответ - ТНГ 😉).

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

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

Общение, а не оправдания

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

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

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

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

Ваш голос имеет значение

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

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

Положитесь на опыт

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

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

Скромные вафли, а не эго-вафли

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

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

Последовательность превыше правильности

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

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

Рассмотрите возможность начисления сложных процентов/эффектов

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

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

Не играйте с мертвыми змеями

Как только решение принято, змея мертва — нет нужды продолжать ее тыкать.

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

Просто убей змею

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

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

Всегда улучшайте

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

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

Обезьяна Хаоса

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

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

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

Ориентированы на продажи, а не на продажи

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

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

Заключение

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

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