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

21

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

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

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

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

Проблемы

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

Вопрос

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

Обновить

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

Охотник джунглей
источник
36
чтобы предсказать очевидный ответ: беги !!
Keppla
3
Если у вас нет чего-то серьезного, вы не говорите нам, что начинайте искать новую работу.
Захари К
11
«Менеджер, а иногда и другие« старшие »постоянно меняют спецификацию требований». Что ж, наличие спецификации даст вам 1 балл по тесту Джоэла. : P
Р. Мартиньо Фернандес
11
Ни одна организация не получила менее 2 баллов по тесту Джоэла исключительно из-за нетехнических менеджеров. Есть ряд вещей, которые вы и другие технические члены команды можете сделать без участия нетехнических менеджеров, чтобы повысить свой счет. У вас нет оправданий винить в этом только менеджера.
maple_shaft
6
Похоже, у вас есть команда по продажам в качестве менеджера программного обеспечения, я сочувствую.
Уайлдпикс

Ответы:

30

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

Запустить.


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

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

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

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

SBI
источник
3
+1 за эту цитату: «Если менеджер не знает, как запустить программу, и если старший соглашается с ней, у вас почти нет шансов исправить вещи».
maple_shaft
17

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

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

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

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

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

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

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

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

Joonas Pulakka
источник
Как насчет того, чтобы указать на мои ошибки? Помогая мне совершенствоваться и учиться.
Охотник на джунглей
4
@Jungle Hunter: Конечно, было бы легче быть в компании, где все было легко настроено, все уже следуют всем мыслимым лучшим практикам и т. Д., Чтобы вы могли быть учениками и подражать другим. Но вы также можете улучшить и многому научиться, взяв на себя ответственность и проявив активность в улучшении своей компании. Совершенствование и обучение в конечном итоге в ваших руках. Другие люди могут помочь, но ваш босс не должен быть одним из них.
Joonas Pulakka
Да, ты прав. Я пытаюсь улучшить, но мои усилия, я думаю, воспринимаются скорее как жалобы, чем как попытки улучшить. Честно говоря, мои усилия оба, но давайте посмотрим, смогу ли я заставить их увидеть вторую половину - попытку улучшить.
Охотник на джунглей
Охотник за джунглями: Я вижу, грань между жалобами и улучшениями может быть нечеткой . Но никогда не больно склоняться к конструктивной стороне.
Joonas Pulakka
4
@Joonas: Я был в компаниях, где я представил VCS, обзоры кода, проводил семинары по C ++ и еще много чего, чтобы улучшить качество кода. И я был в компании в значительной степени, как описывает ОП. Если это безнадежный случай, вы должны признать свое поражение и искать работу, где ваша борьба будет вознаграждена, позволяя вам добиться успеха.
ВОО
16

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

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

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

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

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

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

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

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

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

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

HLGEM
источник
1
Этот ответ имеет очень полезные части. И некоторые вещи, которые я считаю неправильными в понимании моей ситуации. Мол, я упоминаю оба случая, никто не оценит, когда это хорошо. Никто не укажет, когда я ошибаюсь. Я использую систему контроля версий, но в команде из 2-3 человек больше никто не делает. Код, когда используется общий доступ, передается с помощью pendrives и Airdrop. Если вы читали комментарий, я думаю, что я также упомянул, что на моем ноутбуке есть настройка Redmine, которая в конечном итоге используется только мной. И то же самое с мерзавцем. Пытался реализовать это для всех. Мой уровень, только что из колледжа. Старший должен кодировать, но не делает.
Охота на джунгли
Я приму совет о создании послужного списка. Я помню, у меня больше свободы на моей сцене, чем в целом. Я мог бы научиться управлять ожиданиями и другими политическими и мягкими навыками.
Охотник на джунглей
3
Прекратите давать им код на pendrives. Если им нужен ваш код, скажите им, что он находится в системе контроля версий, и покажите им, как его использовать.
Уго
1
@JungleHunter Когда они попросят ваш код, скажите им, что вы на полпути через изменения, которые не будут запущены, но они могут получить последнюю стабильную версию из системы контроля версий.
Кирк Бродхерст
1
@HLGEM "Ты плачешь и скулишь"? Слишком сурово, понизить голосование за это одно.
Бен Х
6

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

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

динамический
источник
Он просто смотрит на демо. Говорит, давайте изменим это на это и на то. И затем есть поток жаргонов.
Охотник на джунглей
2
@ Джангл, я бы не стал вкладывать в демоверсии какую-то работу, потому что они непременно меняются, когда он их видит. Он звучит как визуальный человек в первую очередь. Вы пробовали составить для него скриншоты разных вариантов использования? Это может быть намного проще собрать, чем функциональные прототипы.
maple_shaft
@maple_shaft: я думаю, что это отличная идея.
Охотник на джунглей
1
@maple_shaft: Или, может быть, вместо того, чтобы доставлять товар намного раньше времени, доставка к концу. ;)
Охота на джунглей
1
Работа совет от среднего школьника ...
4

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

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

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

Кристоф Клас
источник
1
Я говорил. Я предложил установить систему тикетов, ввести контроль версий, но ему все равно. Или понять. Или оба. Я попросил поговорить с ним о наличии надежной спецификации, и он соглашается. Изменяет это все же. Он не управляется данными. (О, и убрал акцент на текст из моего вопроса.)
Охотник на джунглей
2
@Jungle: Затем запустите как можно скорее.
ВОО
1
Я согласен с sbi, если бы вы еще не просили, чтобы вас сбили, вы могли бы на законных основаниях просто пойти и сделать это самостоятельно. Вы уже потеряли комнату, и если бы я был в вашей ситуации, я бы начал искать.
maple_shaft
3

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

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

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

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

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

maple_shaft
источник
Да! Это я думаю главная проблема. У нас нет сильного технического лидера.
Охотник на джунглей
2

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

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

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

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

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

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

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

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

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

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

Гру
источник
Для «конкурентного преимущества клиента» это ключ. Позже сегодня я спросил его о том, почему он делает это, говорит, чтобы произвести впечатление на клиента. : |
Охотник на джунглей
У меня есть мерзавец / меркуриал для себя. Но сейчас я провожу тестирование вручную. Я должен посмотреть на автоматизированные юнит-тесты.
Охотник на джунглей
1

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

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

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

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

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

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

Без шансов
источник
«Держитесь подальше от технических деталей». Я постараюсь сопротивляться. ;) Спасибо что подметил это.
Охота на джунгли
0

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

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

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

JB King
источник
Я думал о том, чтобы изменить мою команду на команду, в которой есть люди, которые могут посмотреть на мой код. Или попробуйте связаться с людьми, чтобы просмотреть мой код. Как я сказал в вопросах, сейчас нет никого, кто мог бы это сделать.
Охотник на джунглей
0

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

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

JQA
источник
Прежде чем я "бегу", я собираюсь сделать именно это. Если они хотят перемен, я дам им знать, что это не мелкие изменения здесь и там, так что это займет намного больше времени. Когда клиент не выглядит довольным, ему не на что жаловаться, потому что я дал ему то, что он хотел.
Охота на джунглей
@jungle hunter - Не у всех есть возможность уйти с работы, иногда приходится выходить за рамки ситуации. Я обнаружил, что лучший способ справиться с сумасшествием - вернуть его сумасшедшим. Только самые сумасшедшие могут спорить с собственным сумасшествием. удачи.
JQA