Как мне стать ведущим разработчиком? [закрыто]

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

Что я должен иметь в виду при управлении этим проектом? Как я могу убедиться, что все обрабатывается так, как должно?

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

• Понять, какова цель проекта.

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

• Разбивка того, что нужно сделать в задачах. Поймите зависимости между ними.

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

• Понять, что такое открытые вопросы или неясности проекта.

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

• Бизнес ненавидит сюрприз.

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

• Каждый день переходите к более широкой картине.

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

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

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

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

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

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

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

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

• Попробуйте работу в команде - попробуйте немного изучить работу каждого. Прочитайте их код, запустите их функции, попробуйте их тестовые случаи. Не стремитесь к 100% работы каждого, попробуйте немного попробовать у каждого. Дайте им обратную связь, но также поделитесь сильными и слабыми сторонами в команде.

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

• Периодически проверяйте ресурсы команды - люди будут визжать, когда ранее доступный ресурс станет недоступным, но проверять наличие неизвестных причин боли. Где ваши удушающие точки? Есть ли новые инструменты, которые было бы полезно иметь? У большинства команд есть парень, которого я считаю «Охотником за инструментами», который всегда в курсе последних и самых лучших гаджетов. Сбалансируйте разговоры между Tool Hunter и GuyWhoHatesEverythingNew, чтобы найти следующую точку эволюции. Инструменты включают в себя все - SW, HW, физическое пространство, учебные ресурсы.

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

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

• Обзор стоимости и графика- Насколько вероятно, что ваша команда будет иметь в виду их нынешний срок? Как насчет следующего срока? Какова скорость горения ваших расходов? За какие крупные предстоящие покупки вы еще не заплатили? Что осталось от вашего бюджета? Детали меняются в зависимости от того, как вы ведете финансовое отслеживание, но даже в очень неформальной компании вы должны иметь представление как о том, сколько дней / недель / месяцев у вас осталось, и каков ваш конечный срок для текущего продукта. Где-то, так или иначе, кому-то лучше планировать: «Сколько людей нам нужно, чтобы сделать эту работу?» и «можем ли мы позволить себе заплатить им в следующем месяце / квартале / году?». Вам нужно знать эти цифры и иметь информацию о следующих шагах. Вам нужен кристально чистый план на следующую неделю, который вы могли бы объяснить прямо сейчас, если кто-то придет и спросит. Вам нужен довольно хороший план на следующий месяц, это изменится только в 2-3 местах, когда реальность поражает. Вам нужен схематичный план на квартал и генерал на вершине головы за год. В прошлом даже в огромном проекте цифры были просто числами. Послушайте их, но поймите, что никто не подписан кровью.

Это мое первое место в моем списке. Я обычно добавляю к этому, когда меня "ударяет по голове" "сюрпризом" (представьте, что я чувствую чувствительность к области, которую пропустил, а затем мне удается сложить ее в контрольный список. "Сюрприз" с насильственной улыбкой и стиснутыми зубами ).

Также - будьте готовы к переключению Dread Context. Если вы только начинаете в управлении, скорее всего, у вас небольшая команда, и кто-то из менеджеров подумал, что было бы хорошо, если бы вы потратили некоторое время на управление командой и некоторое время на работу с отдельными участниками. Это может быть сделано, но переключение контекста между ними является грубым. План для этого. Заблокируйте время для переключения (как до и после обеда) и знайте свой менее практичный набор навыков и осознайте, что вам придется перетаскивать себя туда первые несколько раз - поэтому зарезервируйте время, чтобы сделать что-то «связанное с большой картиной» и подумайте, что вам понадобится как минимум два часа, чтобы действительно добраться куда угодно.

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

Прочитайте эту книгу: Herding Cats: учебник для программистов, которые возглавляют программистов

Некоторое время назад я подарил эту книгу своему боссу, и он ей понравился. Когда я читал это, казалось, что он знает, о чем говорит. И это так. Автор рассказывает о собственном опыте. Это не собрание «простых истин» менеджера - это слова бывшего программиста. И следует понимать, что это был ЕГО опыт, но ваш может быть другим. Итак, на некоторые вещи стоит смотреть критически. «Менеджер больше не может быть программистом - это важно».

Когда я недавно взял на себя техническое руководство небольшой компанией по продукту, который я не разрабатывал, то, что я нашел очень полезным в управлении вещами, было документировать на простом английском языке работу продукта - функции, которые я задокументировал в огурце, и для внутренних устройств. Я написал объяснения модели объекта и потока через различные контроллеры. При этом я обнаружил, что А) продукт был немного беспорядочным :) И Б) я гораздо быстрее узнал, как работает приложение, чтобы я мог разумно поговорить о том, какие были проблемы и что требовало рефакторинга, или что потребуется для реализации данной функции.

Фотографии также помогают - я не связываюсь с такими продуктами, как Visio, я просто использую цветные карандаши и чистый лист бумаги (на самом деле, я делаю - я работаю дома и часто вместе с моим 2-летним ребенком), но все, что работает для вас, это то, что вы должны использовать.