Проба сил№<...>
Некоторое время назад, такого крутого чувака, как я хорошо попросили узнать, что творится с разработкой некой самописной системки.<...>
Сходу притащился в офис разработчика, раздвинул пальцы веером: «Хде документация?»<...>
Совет клиенту: Прекратить по максимуму доработки и начать создавать новую систему.
«Пусть засунут свою правильность… Не смогут сделать просто, посылай… »
Представьте себя в роли разработчика.

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

Далее выясняется, что речь идёт о системе, за которую два года назад выплачены последние деньги, с того времени только [почти] бесплатных доработок все требуют. Снова появляется мысль об охранниках. Ну да ладно, человеколюбие и репутация торжествуют.

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

Заслуживает уважения то, что он не кричит "КГАМ!", а понимает, что всё спроектировано тщательно и реализовано правильно, но всё равно для него совершенно непонятно. И не удивительно: у вас новички, являющиеся, профессиональными программистами, по кварталу с большими глазами сидят, читают, осознают и потом пересказывают старшим своими словами, а он хочет сам во всём сразу разобраться.

Затем этот человек говорит: "Просто сложность системы стала такова, что при разработке они не могут учесть все возможные факторы!" Спасибо за понимание, но самого главного он не разумеет: так у всех и всегда. Уже потому, что за время разработки изначально неточные требования ещё и изменяются. Только Шура Балаганов точно знал, сколько денег ему нужно для полного счастья. Для того, чтобы побороть эту проблему, придумывают циклические и "гибкие" методологии, и вносят в ЖЦ ПО поддержку. Причём чем больше перфекционизм в первых итерациях - тем медленнее и дороже получается разработка. Только среди хороших специалистов нет альтруистов, которые будут делать все итерации после первой бесплатно.

Затем он предлагает забросить вашу систему и разработать свою, "на коленке". Хочется сказать: вперёд и с песней! Получите систему, которая не удовлетворяет не только функциональным, но и нефункциональным требованиям. Которая работает не только логически неправильно, но ещё медленно и с ошибками, имеет массу искусственных ограничений и заставляет пользователя быть кандидатом всех наук, мазохистом и программистом. "С нуля" всегда кажется самым замечательным подходом, но редко таковым является: надо стараться аккумулировать знания, а не наступать на все грабли самому. Этот же человек уверен, что умнее всех, что всё очень просто, что ему всё понятно, что сейчас шапками закидает - прямо как компания-разработчик критикуемой системы в начале разработки.

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

Проба сил№
1. Я являюсь руководителем проектов по автоматизации.
А для них уже ввели неприкосновенность и вседозволенность?
При всём уважении, если не можете (или не хотите) смоделировать поведение противоположной стороны - как готовитесь к переговорам? Или единственная цель исследования/переговоров - подогнать факты под решение "всё заново, под моим предводительством, бюджет мне"? :)

Проба сил№
2. Надо звать милицию или скорую помощь, но вот если это представитель заказчика который проводит аудит ИТ системы, то можно попасть на конкретные бабки, лучше удовлетворить
Не удовлетворить не получается только группу захвата :) .
Есть бабки, а есть рентабельность. Получить бабки - это хорошо, но потратить для этого ещё больше (бабок, времени, репутации, даже нервов) - плохо.

Проба сил№
3. Гнусная инсинуация и бред!!! Я не знаю где Вы видели программисткую фирму которая занимается ТАКОЙ благотворительностью... В данном случае, есть очень конкретная сумма которая выплачивается на постоянной основе, плюс оплата проекта.
Согласен, про два года почти бесплатно - предположение, хотя у больших инеграторов подобные убыточные проекты встречаются. А хватит ли этой очень конкретной суммы для оплаты труда хотя бы одного конкретного программиста?

Проба сил№
4. Мне не обязательно отвечать на подобные вопросы, чисто по статусу.
Понты заразны :) .
Это очень правильный вопрос, то, что Вы не смогли [бы] на него ответить, показывает, что к встрече не подготовились, если, опять же, была цель сформировать объективное мнение.

Проба сил№
По договору все необходимое для аудита они предоставить обязаны.
Тогда мне не жалко исполнителей: сами виноваты. С другой стороны - ну предоставили они 180 Мб информации, разве от этого легче стало? Есть такой способ послать - дать информации больше, чем человек способен обработать.

Проба сил№
5. Я способен оценить уровень проектирования и программирования. А то что Вы утверждаете, что я что то не понял, является ВАШЕЙ хужожественной инсинуацией... Наверно Вам так интересней подовать информацию...
Может быть. Но руководитель и ведущий разработчик могут быть одним человеком только в небольших проектах. Поэтому либо (5), либо (1) и (4). Вместе не бывает.

Проба сил№
6. Я фигею уважаемый!!! Значит ли Ваше утверждение, следующее: Мы специально сажаем клиента на иглу,
Сделать клиента постоянным всегда является целью исполнителя.

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

Проба сил№
7. Сделать из простого сложное может любой дурак, обратное намного сложнее.
Сложность бывает естественной и наведённой. Делать что-либо с естественной, которая зависит от предметной области - часто вне полномочий исполнителя, так что обратное не всегда возможно.

Проба сил№
В нормальном бизнесе решения делаются не на один год! Да можно закидать шапками, вот только спустя некоторое время заказчик пошлет такого разработчика. Это так, история (правда любой истории, что никто не извлекает из нее уроков...).
Если требования исполнителя необоснованы - действительно, от него нужно быстрее уходить. Но необоснованность нужно сначала подтвердить медианой цен альтернативных решений 8) .

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

Проба сил№
8. Если бы у нашей бабушки...
Что бы делать конкретный список и проводится АУДИТ ИТ системы... А потом по результатам работы сравниваются реальные и экспертные оценки. Вот так просто и ясно!
А как Вы оцениваете стоимость развития системы, не имея на руках претензий пользователей (списка необходимых доработок и исправлений) и не показав его представителям разработчика?