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

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

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

Почему собственная разработка кажется хорошей идеей

У собственной системы есть очевидное преимущество — её можно делать именно под себя.

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

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

Именно поэтому аргумент «давайте сделаем сами» совсем не выглядит странным.

Проблема в другом: сегодняшние требования почти никогда не остаются сегодняшними навсегда.

Самое сложное — не угадать будущее

В начале проекта довольно легко представить, какой должна быть система.

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

Через несколько лет представление о задаче может оказаться совсем другим.

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

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

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

После запуска работа только начинается

Есть ещё одна вещь, которую легко не учесть при оценке собственной разработки.

Допустим, первая версия готова. Она работает, пользователи довольны, данные загружены. На этом проект формально можно объявить завершённым.

Но приложение продолжает жить.

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

В результате у собственного продукта возникает постоянный жизненный цикл:

исправление ошибок;
обновления;
развитие функциональности;
тестирование изменений;
сопровождение инфраструктуры;
резервное копирование;
поддержка пользователей;
документация.

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

Разработчик тоже становится частью системы

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

Пока он работает над проектом, всё довольно просто: он помнит архитектуру, знает, почему сделано именно так, и может быстро исправить проблему или добавить новую возможность.

Но такая схема создаёт зависимость от конкретного человека.

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

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

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

Сколько на самом деле стоит собственная разработка

Есть соблазн посчитать только время, которое программист потратил на создание первой версии.

Например, получилось несколько месяцев работы — значит, столько и стоил справочник.

Но такая оценка учитывает только начало жизненного цикла.

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

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

Что меняется при использовании готового решения

Готовый продукт предлагает другой подход.

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

Это позволяет не тратить собственные ресурсы на создание того, что уже существует в готовом виде.

Но полностью избежать зависимости всё равно не получится. Просто меняется её характер: вместо зависимости от собственного разработчика появляется зависимость от разработчика продукта.

Поэтому готовое решение тоже необходимо оценивать не только по интерфейсу и списку функций.

На что стоит смотреть при выборе

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

Например, имеет значение:

можно ли установить систему внутри собственной сети;
требуется ли постоянный доступ в интернет;
какие серверные операционные системы поддерживаются;
как выполняются обновления;
как организовано резервное копирование;
как устроены роли и права доступа;
какие возможности есть для импорта данных;
предусмотрены ли интеграции с другими системами.

Не менее важен и сам подход продукта.

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

Готовое решение не всегда лучше

Из всего сказанного не следует, что собственную систему разрабатывать не стоит.

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

Но если задача достаточно типовая, возникает другой вопрос: зачем тратить ресурсы на создание и последующее сопровождение ещё одной системы?

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

Как бы я выбирал

Я бы начал не с вопроса «можем ли мы сделать это сами?».

Скорее стоит спросить: есть ли у организации желание и ресурсы много лет заниматься этим продуктом?

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

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

Итог

Собственная разработка даёт главное — свободу. Можно учесть практически любую специфику организации и менять систему в соответствии с собственными потребностями.

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

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

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

Если ответ отрицательный, возможно, готовое решение действительно стоит рассмотреть.