8 советов по управлению разработчиками для не-разработчиков

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

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

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

1. Помогите им добиться прозрачности в своей работе

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

2. Контролируйте их рабочий процесс

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

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

3. Будьте симпатичны

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

Ведите себя как d**k, и вы не получите сотрудничества, необходимого для того, чтобы хорошо выполнять свою работу.

4. Будьте уважительны

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

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

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

Если разработчик недоволен, он не будет торчать.

5. Убедитесь, что у вас есть технические наставники.

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

6. Слушайте своих разработчиков

Общение не часто является сильной стороной разработчиков.

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

7. Попросите кого-нибудь проверить свою работу

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

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

8. Помните, что вы, вероятно, не эксперт

Если бы вы были, вы были бы разработчиком.