Функциональные спецификации проекта

После формирования Группы внедрения, мы начали встречаться с продавцом системы на собраниях по 2¹/₂ дня приблизительно раз в три недели, чтобы зафиксировать на бумаге конкретные подробности требований к системе, которые мы указали в наших Предложениях о сотрудничестве.

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

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

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

На этой стадии осуществления проекта, мы узнали (опытным путем, конечно), что есть два основных риска, которых нужно избегать, чтобы минимизировать возможные проблемы при разработке ПО:

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

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

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

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

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

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

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

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

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