Что делать, когда у клиента нереальные ожидания? [закрыто]

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

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

Поскольку клиент не является компанией, разрабатывающей программное обеспечение, и из-за различных политик потребовалось около 20-25 дней, чтобы просто дать мне права на мою машину для установки таких компонентов, как Eclipse, Tomcat и т. Д. Даже после задержки с настройкой среды, они все еще ожидали, что я завершу проект в те же два месяца.

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

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

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

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

Я уже работаю по 11-12 часов каждый день и путешествую 3-4 часа, и теперь они ожидают, что я приеду и по субботам.

Я должен сделать все здесь: принять требования, дизайн, код и тестирование.

Посоветуйте, пожалуйста, что делать в таком случае?

_{Дополнительные детали: у нас был список результатов, но затем они добавили еще несколько вещей, сказав, что они также важны. Они также изменили несколько результатов. У них даже нет своего UAT-сервера, они тестируют на самой моей машине разработки через ее IP-адрес.}

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

Ваш менеджер, поскольку он планирует встретиться с ним, должен получить от клиента определенный набор требований - проект должен выполнить A, B, C, D и E. И после того, как он это сделает, он завершен. На этом документе должна быть подпись клиента, согласная с этим списком. Вы должны были иметь это с самого начала.

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

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

Вы проводите встречу, где требуются дополнительные функции? Затем запишите его, отметьте «+ X days to current schedule» на каждом предмете и отправьте его всем участникам. Если вы используете только внутреннюю почтовую систему клиента, дополнительно распечатайте ее, в том числе список получателей to :, cc: и bcc: и аккуратно ее заархивируйте. Кроме того, как сказал GrandmasterB, заказчик должен подписать такие изменения с первоначальными требованиями.

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

Это не для того, чтобы «я тебе так сказал». когда беспорядок наконец ударится о стену - они все равно не будут его слушать. Это ваша страховка, когда клиент предъявляет вам иск, потому что считает, что вы не выполнили договор, или когда ваша компания предъявляет иск клиенту, потому что он отказывает в оплате.

Из того, что вы описываете, видно, что вы участвуете в классическом проекте Death March :

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

Phenomenon хорошо известен, и есть много литературы о том, как действовать дальше, включая, конечно, оригинальную книгу Эдварда Тидона « Смертельный марш: Полное руководство разработчика программного обеспечения по выживанию в рамках проекта« Миссия невыполнима » .

Приведенная выше статья в Википедии является хорошей отправной точкой для поиска дополнительной информации, исследований и рекомендаций для тех, кто вовлечен / заинтересован в проектах марша смерти .

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

Этот способ позволил бы им узнать, что я в курсе происходящего, и, возможно, даже помог бы им направить меня с точки зрения структуры, предусмотренной для этого понятия, например: «Посмотрите, наше текущее состояние близко к описанному в главе Xна Yourdon. Проверьте это вместе с тесно связанной главой и Yт. д ... "

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

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

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

Это серьезно issue in project management . Похоже, вы Project Managerдолжны работать над списком результатов и расставлять приоритеты с клиентом.

Самое главное , ваш PM should discussи согласовать с клиентом сроки (в том числе дизайн и анализ проблемы / решения) в ваших оценках.

Наличие clear estimation of your work loadи поставка предметов проекта избавит вас от стресса, а также добавит душевного спокойствия и уверенности в вашей работе.

Попробуйте использовать Agile-подход , доставляя свои вещи в спринте (2-3 недели) и проводя UAT (приемочный тест пользователя) с клиентом. Помните, всегда делайте планирование спринта перед началом спринта.

Изменить: Из комментариев ясно, что это действительно провал вашего менеджера проекта . Отсутствие надлежащей среды тестирования и / или разработки для серьезного проекта, подобного вашему, является большой дырой для projectпроцесса SDLC.

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

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

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

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

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

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

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

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

Из вики :

Диаграммы Ганта иллюстрируют даты начала и окончания элементов терминала и итоговых элементов проекта.