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

17

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

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

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

ltfishie
источник
12
чтобы избежать такой ненависти , просто поговорите с членами вашей команды. Говорите регулярно, говорите часто, говорите 1: 1 «... Ваша награда за культуру здоровых 1: 1 - явное отсутствие драмы».
комнат
1
Каков ваш титул и ваша ответственность именно за этот предмет? Вы руководитель, старший разработчик, ...?
NoChance
Учитесь у лучших ... youtube.com/watch?v=GjJCdCXFslY
jfrankcarr
1
А если серьезно, я недавно написал эту серию статей, которые могут оказаться полезными: vbnotebookfor.net/2007/07/25/…
jfrankcarr

Ответы:

19

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

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

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

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

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

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

прецизионный самописец
источник
2
Правильно. Главное - быть готовым к тому, чтобы ваши технические звезды принимали решения, отличные от тех, которые вы бы приняли. Если вы можете сделать это, то все (кроме, конечно, высшего руководства) будут счастливы и продуктивны.
Даниэль Р Хикс
«Так что вам не нужно говорить« Вот лучшее, что можно использовать », вы можете сказать:« Я использовал это на Java, знаете ли вы эквивалент .NET? » В большинстве случаев , если эквивалентный инструмент существует , то он будет начинаться с «N», так что вы можете вообще найти их сами.
Дэн Нили
Имейте в виду, он помечает себя как «Ведущий разработчик», а не «Менеджер проекта». По моему опыту, это две очень разные вещи.
Вонко вменяемый
@WonkotheSane: Это правда, что OP относится к руководителю проекта, руководителю группы и ведущему разработчику, как будто они все одно и то же, и это сбивает с толку. Но я взял реплику из контекста, в котором они используются.
pdr
@pdr - согласился, почти. Часть о «я могу использовать шаблоны проектирования и ОО-парадигмы» заставляет меня задуматься.
Вонко вменяемый
6

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

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

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

Даниэль Р Хикс
источник
4

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

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

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

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

Калеб
источник
2

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

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

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

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

S.Robins
источник
3
Я бы сказал, что это полная противоположность тому, что делать в качестве менеджера. Может быть заманчиво войти и выбросить какой-то код, но это больше не ваша работа ... ваша задача - позволить вашей команде делать то, к чему вы их наняли, и доверять их опыту и суждениям. Попытка достичь скорости на другой платформе неэффективна.
Майкл Браун
@MikeBrown Это верно только в том случае, если позиция является управленческой. Все занимаемые мною руководящие должности потребовали значительного времени на программирование в дополнение к управлению проектом, планированию и другим обязанностям, которые вы ожидаете от этой должности. Если бы ОП сказал, что он должен быть менеджером , тогда мой ответ был бы совсем другим.
С.Робинс
Ты прав. Я предполагал менеджера из-за того, что это была технология, с которой у него не было опыта. Сделайте правку, и я отменим свое отрицательное голосование :)
Майкл Браун
@MikeBrown Я не уверен, что ты чувствуешь, мне нужно отредактировать. Я ответил на вопрос ОП, основываясь на его собственном заявлении о том, что он должен был стать руководителем проекта ... однако я немного расширю ответ. :)
S.Robins
О, это не то, что я чувствовал, что вам нужно редактировать ... просто потому, что ТАК не позволил бы мне изменить мой голос без редактирования :(
Майкл Браун
1

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

Торстен Мюллер
источник
1

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

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

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

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

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

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

Удачи!

tehnyit
источник
0

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

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

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

Harisha
источник
0

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

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

Крис Чоу
источник
-1

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

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

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

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

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

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

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

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

Правда.

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

С. Лотт
источник
2
Иногда люди, работающие над проектами с открытым исходным кодом, не используют лучшие доступные инструменты или даже не следуют стандартам (хорошие практики). Я знаю несколько проектов с открытым исходным кодом (я не хочу их называть), которые действительно очень плохи с точки зрения использования правильных инструментов или даже следования отраслевым соглашениям.
Кристиан П
@ChristianP: Хотя есть несколько менее звездных проектов с открытым исходным кодом, легко найти большие, которые довольно хороши. И найти любой проект с открытым исходным кодом в качестве примера лучше, чем вообще никакого примера.
S.Lott
Я согласен, что любой пример лучше, чем ничего. Но при поиске лучших практик, инструментов и т. Д. Можно узнать больше из хорошего проекта с открытым исходным кодом, даже если проект не решает ту же проблему.
Кристиан П