Установление реалистичных ожиданий по срокам

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

Обычно взаимодействие происходит по следующей схеме. Клиент предлагает функцию, которую он хочет добавить, функцию X. Функция X будет хорошо выглядеть в следующей версии приложения, которая через 6 рабочих дней. На этом этапе запрос функции должен пройти утверждение, и часто существуют другие зависимости, с которыми необходимо иметь дело. В конце концов, N дней спустя, запрос на добавление функции передается моей команде. Даже если исходная мертвая черта (которая была установлена ​​менеджером, не являющимся разработчиком) была достижима, она больше не существует. Моя команда обвинена, чувствует себя обескураженным, и есть общая атмосфера поражения , я чувствую себя обескураженным и побежденным.

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

Ребята, вы были в подобных ситуациях? Что у вас / не работает?

Вам действительно нужно поговорить с вашим боссом об этом и установить некоторые основные правила:

• Крайний срок не является крайним сроком, если вы не делаете это.
• Оценка не является оценкой, если вы ее не дадите, и тогда это «оценка», а не жесткий срок.

У «Чистого кодера» Роберта Мартина есть действительно хорошая глава о том, как сообщить об этом вашему боссу. Это не ваша вина, если отдел продаж делает невозможные обязательства.

Когда вы получаете новую функцию, вы оцениваете ее и используете PERT, чтобы получить распределение вероятностей. «Я должен сделать это за 4 дня, но это может занять целых 8». Стоять на своем. НИКОГДА не договаривайтесь об оценке с продавцом, вы в конечном итоге совершите невозможное.

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

Ребята, вы были в подобных ситуациях? Что у вас / не работает?

В основном то, что работает, говорит правду правде.

Соберите факты. Представьте факты. Оставьте клиента учиться (или не учиться) в своем собственном темпе.

Моя команда обвиняется, чувствует себя обескураженным, и в ней царит атмосфера поражения.

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

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

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

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

В противном случае, я думаю, вам нужно постараться и продолжать вбивать это долото в каменную стену, которая является менеджером проекта / клиентом, менеджером / продавцом, который работает с клиентом и согласен с этими сроками. Я часто забивал тот факт, что если они соглашаются, что что-то займет 5 дней, то они, очевидно, говорят о 5-дневной разработке, что означает, что это займет 5 дней с момента, когда вы его получите (а не когда они кладут трубку вместе, а затем тратят следующие два дня написание причудливого слова doc).

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

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

По сути, мне это не нравилось, и как бы я ни старался, процесс не стал идеальным. Однако мне удалось кое-что улучшить.

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

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

Это хорошее начало, когда вы напоминаете клиенту, что ваша начальная дата позже, чем дата, когда они запрашивают эту функцию. Кроме того, необходимо , чтобы поговорить с кем делает первоначальный разговор с клиентом , чтобы получить подробную информацию о функции так , чтобы они могли сказать клиенту , в то время , что лучше срок будет. Поскольку вы уже общаетесь с клиентом, вы можете просто сказать: «Так кто же в отделе Y согласился на этот срок?»

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

Исправить поток информации.

• Если вы должны общаться с клиентом, вынудите всех участников проекта (включая клиента) всегда взаимодействовать с вами напрямую .

К сожалению, власть в основном берется вами, а не дается вам другими.

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

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

Клиент предлагает функцию, которую он хочет добавить, функцию X. Функция X будет хорошо выглядеть в следующей версии приложения, которая через 6 рабочих дней. На этом этапе запрос функции должен пройти утверждение, и часто существуют другие зависимости, с которыми необходимо иметь дело. В конце концов, N дней спустя, запрос на добавление функции передается моей команде. Даже если исходная мертвая черта (которая была установлена ​​менеджером, не являющимся разработчиком) была достижима, она больше не существует.

Эта система планирования кажется странной, если не сказать больше.

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

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

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

К сожалению, я мало что могу сделать, потому что я не нахожусь здесь во власти.

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

Это похоже на то, что я оправдываюсь.

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

Чтобы ответить на некоторые другие ответы.

К сожалению, власть в основном берется вами, а не дается вам другими.

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

Вы не берете власть и не боретесь с ней, но работаете с ней, пытаясь приручить ее и заставить ее работать на всех.

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

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

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

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

Я предполагаю, что ваша команда выполнила эти сроки в прошлом.

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

Если ничего не помогает, уходите.

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

Убедитесь, что у вас есть много документации CYA. Дайте понять всем участникам, что вы храните эти документы. Я отправил такие записи по электронной почте на мой личный адрес электронной почты и CC'd моего босса, который был очень успешным.

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

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

Теперь поговорите со своим боссом по следующим направлениям:

У нас было X доступных человеко-часов между датой начала проекта Y и крайним сроком Z.
Проекту требовалось X + C человеко-часов для завершения.
По другим проектам предъявлялись аналогичные требования.
Нам понадобятся дополнительные программисты Q, чтобы достичь потенциала, необходимого для удовлетворения ожиданий.
... конечно, если бюджеты ограничены, возможно, мы могли бы работать с менеджерами проектов, чтобы уделять больше времени их оценкам, чтобы мы могли недооценивать и переоценивать (не забывайте говорить о банальном управлении)