Чтобы успешно конкурировать на современном рынке, компании нужна правильная технология, причем в каждом отдельном случае она будет своя. Но далеко не всегда ясно, какое решение для конкретной компании будет лучшим. Кто-то может воспользоваться готовыми или адаптированными программными платформами, а кому-то показано создавать заказную систему с нуля.

С этим столкнулась и наша фирма Automated Systems Design (ASD), занимающаяся разработкой, установкой и сопровождением информационных транспортных систем. На полной ставке у нас работает более тридцати служащих, которые взаимодействуют с двенадцатью тысячами авторизованных дилеров ASD и сотнями заказчиков. И дилеры, и заказчики являются пользователями программных систем, выпускаемых нашей фирмой.

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

С самого начала мы не предполагали строить именно заказную программную платформу. Команда, составленная из руководящих работников ASD, прежде всего занялась выработкой требований к программной платформе. Затем был проведен анализ существующих ERP-систем на предмет удовлетворения этим требованиям.

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

Мы оказались перед выбором — то ли установить несколько отдельных систем, которые не так-то легко интегрировать в единую систему, то ли установить одно ERP-решение, ориентированное на один из видов нашего бизнеса, но не имеющее средств поддержки других сторон нашей деятельности.

Взвесив все “за” и “против” и не найдя подходящей системы, мы решили начать разработку своей собственной программной системы, получившей название OMNI. Предполагалось, что в ней будет храниться вся наша бизнес-информация, которая одновременно могла бы быть видимой и для наших пользователей.

Положительные решения

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

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

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

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

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

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

Кроме того, персонал при этом подходе смог научиться работать с новой системой в тестовой среде, а не в режиме реальной работы, когда над людьми довлеют сроки выполнения проектов.

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

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

Отрицательные уроки

Совместное планирование проекта. Мы потратили довольно много времени на совместное обсуждение планов развития проекта, но позже осознали, что этому нужно было уделить еще больше внимания. Практика показала, что те вопросы, которые не поднимались в совместных обсуждениях, обязательно всплывают позже и решать их следует неотлагательно, чтобы не задерживать работу. То есть почти всегда более продуктивно будет затратить дополнительное время на обсуждение, чтобы затем не приостанавливать проект для разрешения проблемы, которая не была обсуждена.

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

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

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

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

Заключительные советы

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

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

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

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