Устойчивость к тестированию производительности для переписывания большого взрыва?

Question

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

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

Какие предложения есть у каждого для решения подобных ситуаций в будущем? Как лучше всего информировать менеджеров / клиентов о необходимости такого рода тестов?

Я показал им руководство по производительности Microsoft на CodePlex, вместе с его резкими предупреждениями от опытных профессионалов на начальных страницах. Я также показал им книгу "Выпусти это!" и руководство, которое его автор дает о "3 утра вызов". Это окончательно убедило их неохотно, но правда в том, что это должно было стать приоритетом при разработке и частично измеряться во время разработки до окончательного полного тестирования системы.

Многие менеджеры и инженеры старой школы, которые писали только ASP, но никогда не писали .NET, привыкли все кодировать самостоятельно и не понимают всех вариантов кэширования, настройки и мониторинга работоспособности в новых приложениях .NET.

Спасибо

Answer 1

То, что вы не поняли (а многие инженеры не понимают), это то, что это была «ситуация с продажами», а не инженерная. Неважно, является ли клиент внутренним или нет, процесс в основном такой же.

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

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

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

Answer 2

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

Answer 3

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

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

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

Риск: производительность системы не соответствует ожиданиям пользователя

Вероятность: неизвестна

Воздействие: конечные пользователи покидают сайт из-за чрезмерной загрузки. Проект провалился.

Стоимость воздействия: $$$ независимо от стоимости вашего проекта.

Смягчение: двухнедельные тесты производительности.

Стоимость смягчения: $$$, сколько вы думаете, это будет стоить времени и денег

Рекомендация: запустите тест производительности для количественной оценки риска.

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

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

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

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

Answer 4

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

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

Вы все еще можете выполнять работу с точкой доступа; вам просто нужно дать острым волосатым начальникам понять, что вся ваша работа направлена ​​на достижение реальных бизнес-целей.

Answer 5

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