Разработка по продавцом

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

Это, вероятно, наиболее опасная часть проекта, где вы, как заказчик, имеете наименьшее влияние на процесс. В теории, именно здесь продавец (используя Функциональные спецификации проекта) модифицирует и подгоняет под ваши требования применение ПО.

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

Мы узнали, что в ожидании периодических встреч, например, раз в месяц, мы предоставляли больше времени, чем нужно для исследования любой проблемы с ПО. Продавец, по вполне понятным причинам, вовсе не стремился раскрывать проблемы при разработке ПО. Чем больше у продавца времени, тем больше возможностей, чтобы выбраться из «пике». Однако если он подлетал слишком близко «к земле», то «крушение самолета» становилось неизбежным.

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

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

То, что осталось от первоначального плана действий

Наш продавец порекомендовал и мы, наконец, согласились (т.к. другого приемлемого варианта не было), разделить систему на Стадию 1 и Стадию 2 проекта. Стадией 1 станет базовая система отслеживания, использующая радиотерминалы, но управляемая операторами.

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

Стадия 1 позволила нам достичь почти совершенной точности в местоположении и количестве нашей продукции. Это позволило решить нашу самую большую проблему при хранении готовой продукции навалом — где конкретно находится продукция?

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

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