Наша команда завершила наш проект раньше срока! Что теперь?

У меня есть 1 проект, и похоже, что мы опережаем время в этом. Мы сказали клиенту, что проект будет готов через месяц, а разработчик выполнил его за 2 недели. Что делать в этой ситуации?

Ответы (5)

Начните с высоких 5 все вокруг! :)

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

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

И если вы действительно закончили, то празднуйте. Успех — это то, что нужно признать.

+1 за возврат клиенту. Редко когда вы строите именно то, что они хотели. То, что вы думаете, что поняли это, не означает, что вы это делаете. И если вы на самом деле закончите раньше, демонстрация, подобная этой, даст им возможность начать использовать ее раньше, запросить дополнительные функции или просто заплатить меньше, чем ожидалось (если они платят почасовую ставку).
Клиента нет в городе. Они расположены вдали...
ВебЭкс! По крайней мере, вы говорите им: «Мы закончили» и смотрите, что они хотят делать дальше.
@ Джоэл, я бы позволил покупателю решить, закончили ли вы. Они могут увидеть демонстрацию и решить, что она не соответствует их требованиям. +1, тем не менее, за предложение встретиться с клиентом, чтобы спросить его мнение. Если они довольны масштабом и досрочной доставкой, это может принести дополнительные «очки брауни».
@John - Джоэл в значительной степени указал на это как на одну из причин, по которой нужно связаться с клиентом. «Моя ставка на то, что у клиента будут некоторые настройки или изменения теперь, когда они его увидели». и "Частое общение с клиентом гарантирует, что вы движетесь в правильном направлении..." +1
@ jmort253 Да, согласен. Мой комментарий относился к комментарию Джоэла, они должны сказать им: «Мы закончили». На мой взгляд, готов кто-то или нет, в конце концов, решение клиента, а не решение разработчика. Но опять же, могут быть и другие факторы.
@john - Хороший вопрос. Я думаю, что Джоэл это понимает, и я думаю, что вы это понимаете, но, возможно, Джоэлу стоит уточнить это в ответе, чтобы никто не истолковал это неправильно. :) Конечно... Джоэл специально не использовал слова "Все готово". Это твои слова ;)
@John- Действительно хороший момент. Слова обладают огромной силой, и мы должны быть осторожны с ними, чтобы они не увели нас по темной тропе. Сказать «Мы закончили», вероятно, немного грубо и может привести к плохим результатам, если вы на самом деле этого не сделаете. Что-то вроде "Насколько мы поняли, мы завершили функциональность, соответствует ли она вашим требованиям?" Конечно, если у вас есть четкие критерии приемлемости, вы об этом узнаете.

Я бы повторил ответ Джоэла о проверке с клиентом, а также упрощенный ответ о полировке.

Тем не менее, несколько других мыслей на тему «вы уверены, что закончили»:

У вас есть месячный проект, разработанный за 2 недели. Есть ли план тестирования разработанного программного обеспечения? Либо с точки зрения функциональности, либо с других менее заметных аспектов, например производительность под нагрузкой, безопасность, удобство использования, доступность и т. д.

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

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

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

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

Я думаю, что это отличный момент. Вполне возможно, что проект, казалось бы, был завершен досрочно просто потому, что команда не поняла требования. +1
Вполне возможно, что это ошибка планирования — ведь дисперсия идет в обе стороны. Просто потому, что ИТ-индустрия обычно недооценивает, иногда она может и переоценивать. Иногда вы думаете, что что-то может быть сложным и допускаете непредвиденные обстоятельства, но оказывается, что разработчик уже делал что-то подобное раньше или находит повторно используемые компоненты, которые ускоряют работу, и все делается заранее.
@Kris - В любом случае, команда не должна выпивать шампанское, пока не поговорит с клиентом и не согласится с тем, что оно действительно завершено. Хотя я с вами, иногда действительно случается, что что-то действительно делается.
согласен :) критерии приемки и подписания важны. Я упомянул о приемочном тестировании пользователей в своем ответе - я ожидаю пользовательского тестирования и утверждения до того, как программное обеспечение будет официально доставлено, и все важные окончательные платежи перейдут из рук в руки!

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

Что, если функциональность не соответствует тому, что действительно хотел клиент? Что, если клиент понял, что не объяснил всю свою функциональность? У вас есть возможность пообщаться с вашим покупателем, воспользуйтесь ею. Мое мнение.
Я думаю, это хорошая идея, Джоэл. Спасибо, будем иметь это в виду.
@ simpixelated — отсюда происходит термин «позолота»; добавление вещей, которые не просили, и это обратная сторона ползучести объема. Если вы выполнили проект в соответствии со спецификациями и требованиями заказчика, то продолжать работать над ним сверх этого — просто тратить их деньги без уважительной причины. То, за что вы ратуете, также сопряжено с проблемой риска — вы сделали, и все готово. Но теперь вы добавляете или меняете что-то (без авторизации) и ломаете это, и вам приходится тратить дополнительное время, чтобы исправить это, и, возможно, поставить под угрозу дату окончания.
«Вы можете легко потратить еще неделю или две на тестирование и улучшение (подчеркиваю я) каждую мелочь и при этом сдать продукт вовремя». Похоже, @simpixelated просто предлагает команде убедиться, что качество есть, что нет серьезных дефектов и исправлены мелкие ошибки. Я понимаю, что «позолота» подразумевает добавление функций, которые не требуются, тогда как для меня это звучит так, как будто он просто предлагает потратить время, чтобы убедиться, что все точки над «i» и «t» перечеркнуты, что-то вроде перечитывания предложения + исправления. ошибки перед отправкой. +1
@JMort - может быть. Именно его использование фразы «вне ожиданий» привело меня к позолоте. Но, возможно, ваше чтение было лучше, чем мое. Спасибо за разную перспективу. +1
@Trevor - Тем не менее, возможно, одному из нас следует отредактировать этот ответ, чтобы сделать этот момент действительно кристально ясным, что «превзойти ожидания» не означает сойти с ума и начать добавлять случайные функции. Думаю, стоит особо отметить, что это время следует использовать только для тщательного просмотра и исправления недочетов. Если вы с Джоэлом неправильно поняли, вполне возможно, что и многие другие тоже :)
Я определенно не намекал на новые функции, поэтому я рад, что это стало ясно. Я больше думал за пределами ожиданий ваших собственных стандартов. Мне также очень нравится идея Джоэла связаться с клиентом, чтобы убедиться, что вы сделали то, что он ожидал.
@ jmort253 Ницца ответил.
@simpixelated - Можете ли вы обновить свой ответ, чтобы было более ясно, что вы не имеете в виду начать добавлять случайные функции? Спасибо за продолжение.
Я думаю, что этот ответ является хорошим примером закона Паркинсона.

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

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

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

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

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

Наша команда завершила наш проект раньше срока! Что теперь?
СпросиСетьПолитика конфиденциальности1y, 0v