1. Составляем как можно больше блок-схем процедур.

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

Программисты не могли "читать между строк" в записанной процедуре, как это могли делать некоторые члены Группы внедрения. В результате, могло быть два различных толкования одной и той же процедуры. Не думайте, что менеджер проекта продавца будет смотреть через плечо программиста и объяснять каждую часть документа.

Если продавец этого сделать не может, то нужно подумать о выделении внутренних ресурсов (из Группы внедрения), чтобы "нянчиться" с продавцом во время этой стадии программирования проекта.

2. Второй большой риск, который может быть опаснее первого, в том, чтобы «перепроектировать» систему. Очень легко для Группы внедрения в своем энтузиазме при проектировании системы потерять чувство реальности.

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

Эти вопросы часто относились к подгоняемому под потребителя ПО, так что значительная часть работы по программированию тратилась на относительно небольшую часть нашего складского бизнеса. К сожалению, наш продавец неохотно говорил "Нет!" в ответ на некоторые наши просьбы, даже несмотря на то (что в то время было нам неизвестно), что мы значительно усложняли требования к программе.

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

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