Один из наших потенциальных Заказчиков задался вопросом - может ли он нанять программистов, и самостоятельно написать CRM систему под свои задачи. Заказчик предположил, что в этом случае затраты на автоматизацию будут низкими, в виде заработной платы одного или двух программистов в течении нескольких месяцев.
Разберем недостатки этой идеи, а именно две основные проблемы, возникающие в случае «самописного» программного обеспечения (ПО):
Проблемы с экспертизой, вкладываемой в функциональность «самописного» ПО
В случае внедрения готового ПО, базовый функционал решения уже прошел испытание временем на сотнях или тысячах других проектов, и содержит в себе экспертизу, или наилучший опыт эксплуатации, из этих проектов. Эта экспертиза реализована во множестве деталей решения, начиная с разделов системы и взаимосвязи функций, заканчивая интерфейсом и размещением кнопок. Облик решения определен архитекторами, и специалистами по интерфейсу – профессионалами в своих областях. Именно они ставят задачи перед программистами, являющимися профессионалами совсем в другой области, в области алгоритмов и программных технологий.
В случае «самописного» ПО, функциональность и интерфейс системы будут определяться по ходу проекта, и исходить из необходимости наименьших затрат человеко-часов для программистов. Функциональность такого решения впоследствии окажется не совсем удобной, или совсем не удобной, для пользователей.
Проблемы с дальнейшим сопровождением «самописного» ПО
В случае «самописного» ПО, основным требованием к программистам будет являться минимальная стоимость – то есть написание программного кода в минимальные сроки, с минимальным числом задействованных специалистов. Результатом такой работы будет являться так называемый «Код с запашком», из которого вытекают следующие проблемы:
Нормальный программный код
Программный код, отвечающий здоровой практике программирования, будет лишен перечисленных выше проблем, и будет дешевым в дальнейшем сопровождении, но разработка такого кода требует программистов высокого уровня, и существенного объема часов кодирования. Разработка такого кода является дорогостоящим мероприятием:
Заключение договора на разработку ПО
В договоре на разработку «самописного» ПО трудно юридически сформулировать ответственность Исполнителя за качество программного кода, то есть за стоимость будущего сопровождения ПО. Возможно попытаться оценить уровень Исполнителя, ознакомившись с программным кодом в других проектах, выполненных ранее этим Исполнителем, и находящихся в эксплуатации. Для такой оценки портфеля проектов Исполнителя возможно:
Разберем недостатки этой идеи, а именно две основные проблемы, возникающие в случае «самописного» программного обеспечения (ПО):
- Проблемы с экспертизой, вкладываемой в функциональность такого ПО.
- Проблемы с дальнейшим сопровождением такого ПО.
Проблемы с экспертизой, вкладываемой в функциональность «самописного» ПО
В случае внедрения готового ПО, базовый функционал решения уже прошел испытание временем на сотнях или тысячах других проектов, и содержит в себе экспертизу, или наилучший опыт эксплуатации, из этих проектов. Эта экспертиза реализована во множестве деталей решения, начиная с разделов системы и взаимосвязи функций, заканчивая интерфейсом и размещением кнопок. Облик решения определен архитекторами, и специалистами по интерфейсу – профессионалами в своих областях. Именно они ставят задачи перед программистами, являющимися профессионалами совсем в другой области, в области алгоритмов и программных технологий.
В случае «самописного» ПО, функциональность и интерфейс системы будут определяться по ходу проекта, и исходить из необходимости наименьших затрат человеко-часов для программистов. Функциональность такого решения впоследствии окажется не совсем удобной, или совсем не удобной, для пользователей.
Проблемы с дальнейшим сопровождением «самописного» ПО
В случае «самописного» ПО, основным требованием к программистам будет являться минимальная стоимость – то есть написание программного кода в минимальные сроки, с минимальным числом задействованных специалистов. Результатом такой работы будет являться так называемый «Код с запашком», из которого вытекают следующие проблемы:
- У Заказчика со временем обязательно возникнет необходимость внести изменения в какую-либо функцию ПО, но выяснится, что такие изменения невозможны, так как не заложены на уровне базовых принципов реализации этой функции, или требуется переработка больших участков кода.
- Устранение выявляемых ошибок или сбоев в работе ПО, требует большого объема часов разработчика, из-за сложностей с выявлением источника ошибок, или работы по переписыванию больших участков кода.
- Понять что-либо в «Коде с запашком» может только программист, написавший его, в течении ограниченного времени, прошедшего с момента написания. Другим разработчикам может быть проще написать это ПО заново, чем разобрать такой код, или потратить время на переработку кода в нормальный. См.статью «Рефакторинг».
Нормальный программный код
Программный код, отвечающий здоровой практике программирования, будет лишен перечисленных выше проблем, и будет дешевым в дальнейшем сопровождении, но разработка такого кода требует программистов высокого уровня, и существенного объема часов кодирования. Разработка такого кода является дорогостоящим мероприятием:
- Данные, интерфейс и логика должны быть разделены на три отдельных компонента: модель, представление и контроллер.
- Все сущности должны быть описаны с помощью объектов.
- Сам код должен быть написан с учетом общепринятых правил по отступам, именам, и комментариям.
Заключение договора на разработку ПО
В договоре на разработку «самописного» ПО трудно юридически сформулировать ответственность Исполнителя за качество программного кода, то есть за стоимость будущего сопровождения ПО. Возможно попытаться оценить уровень Исполнителя, ознакомившись с программным кодом в других проектах, выполненных ранее этим Исполнителем, и находящихся в эксплуатации. Для такой оценки портфеля проектов Исполнителя возможно:
- Привлечь сторонних программистов для ознакомления с кодом.
- Ознакомиться с работой ПО из этих проектов.
- Попросить Исполнителя в присутствии Заказчика внести изменения в какую-либо функцию ПО.
- Ознакомиться с документацией ПО (инструкция пользователя, справочное руководство, видеоуроки, и т.п.).
- Получить обратную связь от пользователей ПО.
Комментариев нет:
Отправить комментарий