Как вести девелоперский проект без технической экспертизы

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

Теперь я нахожусь на другой стороне зеркала. Я являюсь ведущим разработчиком толстого клиента, который будет реализован на C #, однако мой опыт заключается в создании веб-приложений на Java. Хотя я знаю, что могу использовать шаблоны проектирования и ОО-парадигмы на любом языке, я теряюсь, когда дело доходит до стандартов кодирования, инструментов жизненного цикла проекта и процедур выпуска / распространения. Я не сомневаюсь, что смогу освоить основы в течение месяца или двух, но есть определенный опыт, который можно получить только со временем.

Что мне делать, и как мне не стать лидером проекта, которого я ненавидел, когда разрабатывал?

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

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

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

Управление может, в зависимости от уровня квалификации ваших разработчиков, означать консультирование их, когда они просят об этом. "Вы смотрели в Spring.NET?" (обратите внимание на отсутствие инструкций там), это очень хорошая вещь, чтобы сказать. Кроме того, «Google вокруг, посмотрите, что делает остальной мир, мы не первые, кто сталкивается с этой проблемой».

В некоторых отношениях, как опытный Java-разработчик, вы можете оказаться в лучшем положении, чем большинство в этом. Большинство фреймворков и технологий Java имеют аналогичный эквивалент в .NET. Таким образом, вам не нужно говорить «Вот что лучше всего использовать», вы можете сказать: «Я использовал это в Java, знаете ли вы эквивалент .NET?»

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

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

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

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

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

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

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

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

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

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

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

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

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

Похоже, что здесь есть несколько вопросов.

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

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

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

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

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

Удачи!

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

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

Не упустите свою возможность.

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

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

Я заблудился, когда дело доходит до стандартов кодирования, инструментов жизненного цикла проекта и процедур выпуска / распространения.

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

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

Загрузите их рабочий код. Прочитайте это.

Выясните, какие инструменты они используют. Используй их.

Узнайте, как создать и выпустить проект с открытым исходным кодом. Постройте это и выпустите это.

Проект с открытым исходным кодом (с несколькими участниками) проиллюстрирует лучшие практики.

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

Правда.

Учитесь у открытого сообщества.