Изменения

В своей работе в разной степени мы используем принципы [https://ru.wikipedia.org/wiki/Экстремальное_программирование экстремального программирования]. Мое самое любимое положение из него - код должен максимально быстро начинать приносить реальную пользу (прибыль!) нашим клиентам. При классическом подходе к разработке, как я уже писал, сначала пишется документация всей доработки, потом разбивается на подзадачи, реализуется, тестируется, отлаживается и т.д., на все это уходит куча времени и денег. Потом ее пытаются сдать заказчику, и тут оказывается, что задачу изначально не совсем так поняли. Чтобы этого всего избежать, мы сходу пишем небольшие куски, и сразу, даже без тестирования, отдаем заказчику. Да, при этом могут быть ошибки. Но заказчик сразу начинает пользоваться, решать свои бизнес-задачи, т.е. экономить деньги. Ошибки, замечания, пожелания, которые он обнаруживает уже в промышленной эксплуатации, а на не на примере [https://ru.wikipedia.org/wiki/Научный_юмор#Сферический_конь_в_вакууме сферических коней в вакууме], как это делает тестировщик, в реальном времени передаются разработчикам и так же быстро устраняются. В результате мы получаем огромный прирост эффективности - в разы, если не на порядки. С одной стороны сильно сокращаются издержки на документирование, тестирование, случаи решения несуществующих задач, а с другой стороны - клиент получает самую свежую функциональность со скоростью горячих пирожков и сразу начинает на этом зарабатывать. Пусть эта функциональность и не обязательно полная или надежная - это лучше, чем ничего. Иногда задача даже может остаться не очень доделанной - главное, что она решает поставленную перед ней конкретную задачу на конкретных данных. Поэтому иногда бывает, что клиент пытается воспользоваться функцией, а она не работает, т.к. писалась для конкретной задачи. С точки зрения клиента это <rspoiler text="глюк">- Исправьте немедленно!!!</rspoiler>, а с нашей - это недофича, которой могло и не быть, и <rspoiler text="никто бы не узнал, что она могла быть">Если, конечно, она не заявлена в перечне функциональности системы: в этом случае мы должны обеспечить корректность ее работы в соответствии с документацией и/или здравым смыслом</rspoiler>.