Какие типичные заблуждения есть об информационных системах?

• Недооценка того факта, что между идей, и ее реализацией в виде продукта существует существенная разница. Надо понять, что даже относительно простая идея типа учета товаров на складе, для реализации должна быть однозначно описана вплоть до нажатия на клавиши, должны быть задокументированны все возможные ситуации и поведение в них программы. Затем должна быть проведена разработка архитектуры, которая позволит за приемлемые деньги и время получить приемлемое быстродействие и желаемую функциональность. Затем должны быть описаны и созданы многочисленные тесты, которые позволят избавить программу от ошибок. Все это огромный труд.
• Не верьте оптимистичным ожиданиям, калибруйте время. Гради Буч для решения проблемы краха проектов от недооценки трудоемкости предлагает следующие умножать на калибровочные коэффициенты свои ожидания. По моему опыту они таковы. Если пользователю пришла в голову идея, и он может ее описать в виде рисунка экранной или печатной формы с исчерпывающим пояснением, то по моей оценке на одну такую форму следует отвести от 1 до 5 дней (в среднем 2-3). Надо спросить разработчика (интервал торга я указал), а затем умножьте срок на ДВА и не прогадаете. Дело в том, что разработчик не может включить  время  вашего тестирования и свою работу над ошибками и пожеланиями, а также некий политический торг вокруг этого.
• Все решают люди. Избавляйтесь от дилетантов и насаждаемых ими заблуждений! Предположим у вас есть специалист, который говорит нечто типа "Ха! Это все ерунда! Я (мой знакомый программист или студент и т.д.) это сбацает за пару дней! В фирмах разрабатывающих программы одни жулики, мошенники и бездельники! Я тот самый светоч, который вам нужен!" и т.д., то гоните его пока не поздно. Минимум потеряете время, максимум деньги. Грамотный специалист в информационных технологиях отвечает следующим критериям:
  1) Он фактически ни когда не дает абсолютно отрицательных и абсолютно положительных отзывов, всегда его оценки условны. Более того, чем выше квалификация, тем более настроен специалист искать только положительные моменты, они для него еще одна возможность решить проблемы. НАСТОЯЩИЙ СПЕЦИАЛИСТ РЕДКО ЧТО-ТО ОДНОЗНАЧНО ХВАЛИТ, НО ФАКТИЧЕСКИ НИКОГДА НЕ ДАЕТ ОТРИЦАТЕЛЬНЫХ ОТЗЫВОВ. Если человек видит в деле только черное или только белое, скорее всего его квалификация недостаточна - он слеп.
  2) Грамотный специалист четко блюдет профессиональную этику, не делает безапелляционных и эмоциональных заявлений. Лишенный аргументации эмоционал наверняка испортит со всеми отношения, и сотрудничества не получится, даже если он поправит квалификацию. НЕ ВЕРЬТЕ ЭМОЦИЯМ.
  3) Требуйте от профессионала список его выполненных (и успешных!) работ и проверяйте его личный вклад. ВЕРЬТЕ ТОЛЬКО ОПЫТУ. Если человек никогда не делал нечто, то он может заняться этим только как ученик.
  4) Грамотный специалист должен иметь широкое образование и широкие взгляды, чтобы видеть проблему в комплексе, но его специализация должна быть узкой для высокого качества. Слова настоящего профи: "Я ЗНАЮ, КАКУЮ ПРОБЛЕМУ ВЫ ИМЕЕТЕ В ВИДУ, Я ДАЖЕ ЗНАЮ, КАК ОНА РЕШАЕТСЯ, НО Я ЗНАЮ КЛАССНОГО СПЕЦИАЛИСТА, КОТОРЫЙ ЛУЧШЕ ВСЕХ ЕЕ МОЖЕТ РЕШИТЬ".
  5) Профи как лидер должен быть агрессивен и настойчив (ему, извините, нужно отъиметь кучу народа, которым до лампочки, что начальству нужен порядок), как исполнитель профи должен быть аккуратен и обязателен. Но фактически должен обладать обоими качествами. Скромность часто граничит с бездарностью и беспомощностью, а уверенность и решительность может граничить с самоуверенностью и бахвальством. ИЩИТЕ БАЛАНС, ПРОВЕРЯЙТЕ ФАКТЫ.

• Заблуждения о стандартности решений. Довольно часто можно увидеть картину, приходит разработчик с вопросом, "а как сделать?" ему в ответ дают учебник по бухгалтерии (GAAP, менеджменту и т.д.) и говорят, что все стандартно. Мое глубокое убеждение, что тот, кто так поступает, не достаточно квалифицирован в своей области, по крайней мере, удивляет следующее:
  1) Грамотный специалист знает, что он использует не один стандарт, а творчески использует целую совокупность стандартных действий в своей неповторимой комбинации и особенностях.
  2) Человек не в состоянии объяснить, как конкретно в его конкретном случае делается нечто
  3) Человек не в состоянии понять, что так как он скажет, так и сделают вплоть до нажатия клавиш. Апатия к специалисту, который автоматизирует твою область это признак равнодушия к служебным обязанностям или скрытое несогласие и саботирование политики автоматизации.
• Заблуждение о том, что автоматизация нужна служащим. ЗАКОН: автоматизация нужна в первую очередь начальству. Служащие выполняют свои функции, поэтому их совсем не радует необходимость переучиваться, не говоря о том, что чисто исполнительские операции при автоматизации сокращаются и это может привести к сокращению. Поэтому, скорее всего, автоматизации будет оказано сопротивление. Менеджеры, которые ожидают выигрышей от автоматизации, должны быть особенно последовательны и требовательны к своим работникам в процессе внедрения.
• Заблуждение об полной ответственности разработчиков. Следует помнить, что успех внедрения зависит от двух сторон. Разработчик не сможет внедрить систему, если ему не окажут заказчики квалифицированную поддержку. Более того, организованности и квалификации заказчика может просто не хватить для внедрения. Разработчик это как дорогая проститутка, его труд можно купить за деньги. Однако если заказчик заплатил, но потрахаться ему некогда, то ожидать удовлетворения не приходится. Разработчики хорошо себе представляют себе что для любви необходимо участие двух сторон, поэтому заранее готовит себе соломку в случае, если придется столкнуться с тем, что заказчик хочет и не может. ВСЕ разработчики в России продают лицензии и услуги БЕЗ гарантий возврата в случае, если их продукт заказчик не смог употребить (даже для заказных работ, всегда прописаны обязанности ОБОИХ сторон по внедрению). Помните об этом.
• Заблуждение об безошибочности работы программ. Все программы содержат ошибки. Если вам предлагают программу и утверждают, что она не содержит ошибок, то вам нагло лгут либо данная программа содержит очень мало функциональности. Высокая сложность крупных программ и разнообразие вариантов их эксплуатации приводит к тому, что крупные программы содержат огромное количество ошибок. К счастью на большинство из них не так просто наткнуться. Тем не менее, для возникновения ошибки достаточно попасть в специфическую ситуацию использования программы, которую  не проверил разработчик. Чем выше тираж программы тем ниже вероятность, что будете первый, кто встанет "на грабли". Однако если программа дорабатывается ("настраивается") под вас, то вам ходить по граблям разработчика обязательно придется.