Советы для сольного программиста, чья команда будет расширяться в ближайшее время [закрыто]

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

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

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

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

• Контроль версий - вы упомянули, что у вас уже есть сервер SVN, и это здорово. Убедитесь, что вы установили репо и организовали проекты стандартизированным способом.
• Автоматизированные сборки
• Программное обеспечение для отслеживания ошибок / ошибок
• Модульные / интеграционные тесты
• Сервер непрерывной интеграции

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

нанять кого-то более компетентного, чем вы

... и с опытом работы в крупном корпоративном программном проекте.

Они помогут вам индустриализировать ваши процессы, и вы, вероятно, многому научитесь у них.

Вы научите их своей нише рынка.

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

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

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

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

Не имея настоящего титула, я буду «отвечать» за эту команду.

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

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

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

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

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

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

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

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

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

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

Http://www.manager-tools.com Один из хороших источников простых и базовых навыков управления тем, что делать и как делать профессионально . Они делают регулярные подкасты по вопросам управления и профориентации, не говоря уже о значительном вспомогательном каталоге материалов для вас.

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

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

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