Менеджер постоянно меняет спецификацию требований после каждой демонстрации [закрыто]

Фон моей рабочей среды

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

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

На тесте Джоэла мы набрали невероятную оценку 0.

Проблемы

• Менеджер и иногда другие «старшие» постоянно меняют спецификацию требований. Изменения, которые, если будет сделано хорошее проектирование, а не частичные «исправления», требуют изменений в базовом проекте.
• Нет абсолютно никого, кто смотрит на код (вероятно, потому что никто не знает, как это сделать, или даже если это нужно сделать), что означает, что никто никогда не сможет:
  • Оцените сложность проблемы или элегантность решения.
  • Предложить улучшение подхода.
  • Цените качество кода.
  • Укажите, где код может быть улучшен.
• Используется много жаргона, который имеет смысл грамматически, но не имеет смысла каким-либо другим способом.
• Не чувствует, не ведет себя и не работает как софтверная компания.

Вопрос

То, что должно быть сделано? Особенно в том, что нет никого, кто бы указывал на улучшения в моем коде.

Обновить

Чтобы ответить на вопрос HLGEM (и, возможно, других) о том, что я сделал, чтобы попытаться это исправить. Я предложил настроить Redmine и внедрить контроль версий для всех. Я сказал, что рекомендую распределенную (git или mercurial), но также расскажу о централизованных и позволю команде решать. Ответ заключался в том, что все делается и будет сделано в течение нескольких недель. Я не видел этого и не знаю, используют ли его другие подразделения компании.

Краткая версия :

Запустить.

Несколько более длинная версия :

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

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

Я был в подобной ситуации один раз (только не было старшего). Я ушел после ужасного года и никогда не оглядывался назад (кроме как с отвращением).

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

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

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

Опять же, не звучит так незнакомо ;-)

Никто не понимает сложности того, что меня просят осуществить.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У меня также нетехнический менеджер, и я смог увеличить балл по тесту Джоэла с 4 до 8 только потому, что я пошел и сделал их и не спрашивал разрешения.

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

Проверьте http://community.rallydev.com/ у них есть выпуск сообщества, который делает отличную работу по гибкому управлению проектами и отслеживанию дефектов. Это само по себе увеличит ваш счет на Джоэле и обойдется вам НЕ БЕЗ сервера или времени на настройку.

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

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

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

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

Если это проект, в котором ваш менеджер отвечает всем требованиям, вы должны действовать так, как если бы он был вашим гибким клиентом, и объяснять им то же самое (сфера действия <-> сроки компромисса) ).

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

Вот некоторые шаги, которые вам абсолютно необходимо выполнить, и, вероятно, вам придется выполнить их самостоятельно:

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

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

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

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

Менеджеры не обязаны понимать код или сложности. Необходимость понять, ресурсы, стоимость и риск.

Версии исходного кода, качество кода, сложность и т. Д. Являются обязанностью руководителя или старшего разработчика.

Решение состоит в том, чтобы:

1-Определить структуру команды проекта и их обязанности

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

Особенно в том, что нет никого, кто бы указывал на улучшения в моем коде.

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

В то время как вы, вероятно, находитесь в менее чем отличном месте, похоже, это работает в конце? Проекты завершены, и дела идут вперед? Что-то делается? Duct Tape Programmer - это статья о Джоэле, которую вы можете прочитать.

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

Вариант 2 - дать им то, что они хотят. Когда они жалуются на то, что вы говорите «но это то, что вы просили»