Каша из топора

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


Итак, я подрядчик на сложный проект, вы - заказчик, для простоты, - некого программного обеспечения. У меня нет ресурсов генерить хорошие привильные идеи, ну, например, у меня нет квалифицированных разрабочиков и вообще штата, а под каждый проект я иду в государственный институт и набираю студентов первого курса за соответствующую плату. В качестве решения я выдаю то, что мне выгоднее (действительно, - это же бизнес!). Теперь уже это ваша головная боль показать мне почему то, что я сделал, нехорошо. Очевидно, что мне выгоднее делать негибкое решение: его делать банально дешевле, к тому же, легкие изменения, которые в случае настраиваемого решения можно было бы выполнить конфигурацией, для вас обернутся необходимостью разработки, на которой, очевидно, я могу заработать. А куда вам деваться, если я уже выбран? Если вы ничего не понимаете и/или не хотите разбираться/думать, вы согласуете мой вариант "наименьших затрат". Если вы разбираетесь в вопросе (хотя бы на уровне фильтрации бреда), вы будете вынуждены тратить время на проработку со мной предлагаемых мною вариантов: объективно доказывать, что они не соответствуют каким-то там стандартам/практикам (просто сказать, что так "плохо" не получится, так как предложение будет воспринято мною как "дополнительное требование", которое "out of scope"), тратить время на детальное объяснение своих требований, поскольку я, прикрываясь словами "наша работа используется во всем мире (!), и только у вас такие требования", буду поначалу "не понимать" все о чем вы меня просите (особенно здорово, если мы с вами банально говорим на разных языках, это - небольшое, но преимущество, опять же мое). В конечном счете ваша деталлизация спустится до уровня работы моего архитектора, и вы сами за него сделаете его работу. Как видите, в любом случае вы в проигрыше. Что плохого для вас:
- вы тратите свои ресурсы. Поскольку очевидно, что это - моя работа, вы их в таком объеме не планировали;
- как бы ни был я плох как подрядчик, в любом случае я более профессионален в предметной области (ибо я все-таки успешен на рынке, иначе вы бы меня не выбрали), а обмануть любителя профессионалу проще;
- свои непрофессиональные решения я буду потом оправдывать вашими же согласованиями.


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

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


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


Как же вам со мной бороться? Лучше вам, конечно, меня не выбирать, но как это можно сделать:
1. Я должен выбираться в объективном тендере, исключающем коррупцию.
2. Я должен иметь подтвержденный опыт, иметь в штате нужных вам специалистов с подтвержденными компетенциями.
3. Мои подходы к разработке должны соответствовать имеющимся практикам и стандартам, впрочем как и продукты, которые я делаю.
4. Я не должен быть уникальным в каком-либо виде, должна быть настоящая конкуренция. Идеально, если вы как-то проверите, что я не "договорился" со своими конкурентами. Следствие: берите лучше коробочные варианты, а не заказывайте мне разработку, либо держите своих разработчиков и обспечивайте среди них отсутствие "ключевых" фигур.
5. Четко разделяйте ответственность меня и свою. Контролируйте это разделение постоянно.
6. Четко формируйте свои требования, чтобы они не допускали хоть сколько-нибудь свободного толкования. Четко определите что входит в объем проекта и убедитесь в том, что я с этим согласен.
7. Имейте четкое представление о том, что хотите получить. Будьте уверены, что вашими требованиями это покрывается. Можете нанять какого-нибудь стороннего эксперта, обязательно квалификацией не ниже меня и имеющего аналогичный опыт, который поможет вам сформирвоать требования, покрывающие ваши желания, а так же быть экспертом с вашей стороны.
8. Позаботьтесь о том, чтобы у вас были рычаги давления на меня.


Как это не прискорбно сознавать, бизнес циничен. Нам всем нужно смотреть в корень.
Alt text

Большой брат следит за вами, но мы знаем, как остановить его

Подпишитесь на наш канал!

Сергей Солдатов

REPLY-TO-ALL is a double language blog (English/Russian) run by three information security practitioners. Want to discuss information security problems? This is the place.