Как Вы убеждаете верхнее управление, что что-то не может быть сделано? [закрытый]

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

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

Ключевым моментом является то, что они не заботятся о технологиях (это вы уже знаете), поэтому вы должны объяснить, почему это невозможно, в терминах, которые их волнуют:

• Риск
• Зависимости
• Стоимость
• Шкала времени

Когда люди просят об изменении, они обычно думают о преимуществах, но не о недостатках. Что может сломаться, если что-то пойдет не так? Будет ли использовать решение медленнее или сложнее? Обычно они ненавидят слово «регресс».

Это нормально, что вы обязуетесь завершить какую-то работу по определенному графику, но работают ли другие команды в те же сроки? Вам что-нибудь от них нужно, прежде чем вы сможете начать? Собираетесь ли вы зря потратить день, если администратор базы данных победит? Не поменять ли вид базы данных за вас?

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

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

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

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

Важно сообщить об этом как можно скорее, а не за день до крайнего срока.

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

Когда вы ее выдвигаете, приводите аргументы, дайте объяснения, говорите о последствиях.

Что-то вроде "

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

1. вы готовы выполнить задание
2. , которое вы ему дали, хотя
3. вы даете обещание, что с вашими условиями это выполнимо

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

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

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

«Мне нужно, чтобы это работало как амулет до даты X. Точка!» можно было бы иметь дело со следующей структурой. Я понимаю, что для вас важно подготовить X к Y, но, к сожалению, мы не сможем удовлетворить этот запрос. Я могу предложить вам подмножество X от Z.

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

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

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

Если бы в целом крайний срок никогда не работал, это немного сложнее. Создайте план проекта с указанием шагов, которые необходимо выполнить для достижения конечного результата, и времени, которое потребуется для каждой задачи. Покажите доступные часы людей, которые в настоящее время назначены на проект, и над чем еще они могут быть назначены для работы (и приоритет других задач). Затем, когда станет ясно, что часы на выполнение задания> часов, доступных для выполнения задачи, спросите их, что нужно сделать. В большинстве случаев они переносят крайний срок, убирают часть требований или сокращают часы тестирования. Если количество тестов сокращается, убедитесь, что вы им не обращаете на них внимания. Обычно это должен делать руководитель группы, поскольку как разработчик вы можете только предоставить ему информацию, касающуюся вашей собственной части проекта, и спросить его, что делать. Важно сделать все это в письменной форме, так как это документирует выявленные проблемы с соблюдением срока. Также легче вернуться к клиенту с планом проекта в руке и показать ему проблемы с соблюдением сроков. Менеджеры будут игнорировать ворчание по поводу крайнего срока, но труднее игнорировать документ, который ясно показывает, почему крайний срок не работает, и конкретно спрашивает, что делать, чтобы исправить проблемы.