Рассказывать моему менеджеру о важности плана

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

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

В качестве альтернативы, он прав, и я тот, кто должен пересмотреть мой подход к развитию?

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

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

Моя точка описания фона для этой команды три раза:

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

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

Изменить

Я хотел бы консолидировать то, что я взял из ответов; Некоторые из них интуитивно понятны, но не то, о чем большинство думает о повседневной жизни (imo):

Менеджеры, такие как метрики. Правда, но, как полагает М. Фаулер (и я согласен), производительность и качество неизмеримы. Кроме того, у меня нет средств для накопления показателей как "peon". (спасибо Новолакрату и Даффимо).

Там всегда будет сочетание таланта, вы должны представить учебную среду. Мы поддерживаем это в отношении, но я думаю, что для создания этой среды необходимы другие инструменты. (спасибо duffymo).

Помогите слабым, облегчите рабочую нагрузку сильного. Кроме того (в результате?), чтобы представить учебную среду, вовлечь более слабых разработчиков в укрепление их дизайнерских навыков, предоставив им небольшие атомные части проекта для разработки (с одобрением) самих. Это снимает ответственность со стороны более сильных разработчиков, учит более слабых и может быть приемлемым решением для менеджера, поскольку от его высокооплачиваемых сотрудников не требуется время. (спасибо даффимо и Том Андерсон)

ОТВЕТЫ

Ответ 1

2 слова: Блокнот Архитектура

Вы не можете изменить мышление боссов, если в большинстве случаев вы не становитесь боссом.

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

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

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

В Блокноте:

Запишите задачу, которая должна быть выполнена (программа, функция, что угодно).

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

  • "Добавить новые поля в таблицу"
  • "обновить существующие объекты с новым полем"
  • "Добавить новый вызов службы для получения сыра из терки"

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

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

Далее, ваши лидеры возьмут кофе-паузу, чтобы позавтракать утром и спросить у jr, как идет проект, и покажите ему часть дизайна. Если дизайн может использовать некоторое улучшение, возьмите дополнительные 5-10 минут, чтобы объяснить лучший способ и предложить его реализацию, не делайте этого для них, направляйте их на успех.

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

Ответ 2

Это очень сложная ситуация.

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

Какое мышление "слабых" разработчиков всегда нуждается в помощи? Они видят это так? Как принять их от обучения? Они лично исправляют или хотят учиться?

Есть ли в вашей команде культура обучения? Всегда ли члены стремятся улучшить свои навыки, узнать новые вещи?

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

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

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

Будьте осторожны: не каждый видит "лучшие практики" одинаково. То, что очевидно для вас, может быть анафемой для других. Сначала поговорите со своей командой, прежде чем идти к менеджеру. Вы не хотите отчуждать их. Это поможет вашему аргументу, если у вас есть консенсус.

Ответ 3

и приветствуем stackoverflow,

Этот вопрос очень сложно ответить ИМХО. Но похоже, что вам понадобится что-то вроде SCRUM (см. http://en.wikipedia.org/wiki/SCRUM)

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

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

Ознакомьтесь с методологиями разработки программного обеспечения (http://en.wikipedia.org/wiki/Software_development_methodologies) и найдите способ, который соответствует вашим потребностям (или вашей компании). Часто это будет гибким (например, SCRUM) или быстрым вариантом.

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

Ответ 4

Несколько мыслей:

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

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

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

Ответ 5

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

Ответ 6

Возможно, вы могли бы купить ему хорошую книгу.

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

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

Ответ 7

Не полный ответ на ваш вопрос, просто мысль.

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

Ответ 8

Важно отметить, что существуют контрпримеры. Линус Торвальдс заявил, что Linux был разработан без плана или общего дизайна. Но тогда у него было преимущество постоянного контроля/надзора за весь срок службы проекта.

Ответ 9

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