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

Ответ 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

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