Одна из главных задач на моей тарелке - общение с клиентом. Одна вещь, которую я нахожу особенно трудной, это иметь дело со сроками, потому что они предписаны клиентом, и со мной часто не консультируются.
Если вы должны нести ответственность за общение с клиентом, почему с вами не консультируются по вопросам планирования (и составления бюджета), чтобы вы могли передавать эту информацию между людьми, ответственными за них в вашей организации, и их коллегами на стороне клиента? Я думаю, что решение этой проблемы принесет огромную пользу вам, вашей команде и вашему проекту.
Клиент предлагает функцию, которую он хочет добавить, функцию X. Функция X будет хорошо выглядеть в следующей версии приложения, которая через 6 рабочих дней. На этом этапе запрос функции должен пройти утверждение, и часто существуют другие зависимости, с которыми необходимо иметь дело. В конце концов, N дней спустя, запрос на добавление функции передается моей команде. Даже если исходная мертвая черта (которая была установлена менеджером, не являющимся разработчиком) была достижима, она больше не существует.
Эта система планирования кажется странной, если не сказать больше.
По моему опыту, клиент подписывается на определенный выпуск. Они могут представить список функций и изменений, которые они хотят и когда они хотят, а затем договориться с командой, создающей программное обеспечение. Или же они могут предоставить приоритетный список функций для команды разработчиков, а команда разработчиков дает оценки относительно того, когда они могут поставлять различные наборы функций. Есть и другие варианты.
Но одна вещь, которую я никогда не видел, позволила клиенту изменить релиз так поздно, особенно за неделю до релиза. Неправильно подвергать дизайнеров, разработчиков и тестеров такому давлению. Если вы делаете итеративную разработку, если это высокоприоритетная функция, просто добавьте ее в форму невыполненных работ и примите ее как можно скорее. Если это не высокоприоритетная функция, они определенно не нуждаются в ней во время этой версии и могут подождать до следующей.
Я бы порекомендовал установить некоторые базовые правила, которые бы учитывали ваши команды по проектированию, разработке, тестированию и доставке, а также вашего клиента, чтобы обеспечить возможность замораживания, замораживания кода и доставки. Поместите это в письменной форме, получите обязательство от всех, и придерживайтесь этого. Если вы сдвинетесь с места один раз, от вас ожидают больше изгибов, и вы потеряете контроль над процессом.
К сожалению, я мало что могу сделать, потому что я не нахожусь здесь во власти.
Вы не можете быть один. Но, похоже, ваши дизайнеры и / или разработчики и / или тестеры находятся под большим давлением, чтобы соответствовать графику. Вам следует сесть с начальством в команду и объяснить ситуацию. Во-первых, попросите вашу организацию внести свой вклад в улучшение процесса, а затем поработайте с клиентом, чтобы понять, как все будет работать.
Это похоже на то, что я оправдываюсь.
Когда вы начинаете оправдываться, может быть, настало время провести трудный разговор или решающий разговор . Я бы порекомендовал одну из этих двух книг. Их чтение помогло улучшить мои коммуникативные навыки, особенно когда вам приходится сталкиваться с трудной ситуацией, когда напряженность высока со всех сторон.
Чтобы ответить на некоторые другие ответы.
К сожалению, власть в основном берется вами, а не дается вам другими.
Я не знаю, куда Андреа идет с этим. Да, вам нужно исправить поток информации. Но вам нужно поработать с руководителями и клиентом, чтобы все знали, что было (я полагаю, в любом случае) согласовано в начале проекта. Если договоренность по какой-либо причине не работает, пересмотрите ее и перераспределите работу и роли людям, которые лучше подходят для них.
Вы не берете власть и не боретесь с ней, но работаете с ней, пытаясь приручить ее и заставить ее работать на всех.
Проблема в том, что клиенты в основном знают ценность данной функции для бизнеса, но не понимают ее сложности. Просто обсудите и уточните. Всегда.
Эта цитата из loki2302 довольно популярна . Одна из ваших задач в качестве инженера-программиста состоит в том, чтобы убедиться, что нужные люди знают такие вещи, как сложность задачи, время, которое она займет, и какие варианты и риски существуют при выполнении чего-либо. Как ведущий коммуникатор для вашей команды, передача этой информации от вашей организации вашему клиенту, теоретически, ваша работа.