Разработка программного обеспечения — это альтернатива выбору и покупке готовых программ. Часто выбор делается в пользу готового программного обеспечения из-за рисков и проблем, с которыми заказчик может потенциально столкнуться при собственной разработке (путем найма специалистов) или обращения в компанию при разработке программного обеспечения.
Существует несколько наиболее распространенных проблем, приводящих к тому, что либо проект не выходит в свет вовсе, либо заказчик получает продукт, которым невозможно пользоваться. Про эти проблемы, а также способах их избежать, пойдет речь в данной статье.
Отсутствие четкого плана и технического задания
Часто вопрос ставится так — нам необходимо автоматизировать компанию, для этого наймем программиста, пусть автоматизирует. Только что именно он будет делать? От формулирования бизнес-задачи, например “хотим чтобы коммерческие предложения выводились автоматически”, или “надо вести в системе заказы и должны быть звонки клиентов”, до даже начала программирования лежит огромная пропасть, процесс, называемый проектированием. Важно понимать, что это необходимо сделать. Надеяться, что программист выступит в роли бизнес-аналитика, проектировщика, системного архитектора и дизайнера и сделает все эти задачи хорошо — ну, можно попробовать. И некоторые программисты даже обещают это сделать. Есть даже такой термин — крюгеризм.
Нужен проект. И план. Проект — это и есть информационная система, программное обеспечение. Проект включает в себя полное техническое задание и изображения интерфейсов. Обе эти составляющие также могут быть разного качества.
Техническое задание часто путают с функциональным описанием. Когда заказчик говорит, что у него есть техническое задание, то хорошо, если это не просто на один лист набросанные названия разделов, а хотя бы несколько листов с описанием того, как он видит эту систему и что в ней должно быть. Но не стоит путать это с техническим заданием, которое должно содержать:
- Цели и назначение информационной системы;
- Требования к стеку технологий;
- Требования к качеству программного кода и соблюдению стандартов разработки;
- Структуру данных, полное описание будущей базы данных, всех таблиц и полей включая типы этих полей и связи между данными;
- Текстовое описание интерфейсов, всех их элементов и логики работы, которое должно соответствовать прототипам и дизайну;
- Описание логики работы в системе, что необходимо сделать по действиям для достижения результата работы функции системы.
Дизайн системы состоит из изображений или интерактивного макета, всех интерфейсов и их элементов. Дизайн-макет определяет, как будет выглядеть система и позволяет вам, как заказчику, до начала разработки точно понять не только как будет выглядеть, но и как будет работать будущая система. Можно пройтись по интерфейсам представляя действия в системе. Для разработчика интерфейсов — это четкий макет, по которому делается интерфейс. Если оставить внешний вид на милость программисту, то у вас будет одна большая кнопка на весь экран. И это будет соответствовать техническому заданию, ведь в нем сказано, что должна быть кнопка.
Имея техническое задание и прототипы, вы уже можете или нанимать программистов, или обращаться в IT-компании для сбора предложений стоимости реализации, в общем принимать решения.
Для того, чтобы составить такой проект, вы также можете обратиться в IT-компанию. Составить проект самостоятельно достаточно сложно без специальных навыков и знаний, как и найти одного человека который будет и аналитиком и дизайнером — это тоже задача практически невыполнимая.
В данном случае разработку программного обеспечения можно сравнить с постройкой дома. Если вы надеетесь нанять программиста, еще и недорого, чтобы он всё сделал, то это как нанять специалиста, специализирующегося по кладке кирпича и ожидать от него построенный дом. А отсутствие проекта — это сказать мастеру, что дом надо 8 на 10 пожалуйста, желательно двухэтажный.
По причине того, что уже используемые системы являются шаблонными, не поддаются изменениям или эти изменения очень трудоемки, выбирается вариант заказать информационную систему для решения локальной задачи или конкретного бизнес-процесса.
Устаревший или редкий стек технологий
Это можно назвать — что умею, то и делаю. И тут тоже происходит отсылка к проекту, где должны быть указаны технологии.
Очень частая проблема, когда проект или функционал подстраивается под специалиста, который умеет что-то делать на своём языке программирования. При этом одиночные специалисты, как правило, не имеют объективного понимания применимости тех или иных технологий к задачам. Они предлагают написать проект на том, чем умеют и считают лучшим, но лучшим для себя, а не для проекта. Кроме того, в современном мире технологии вообще разделены на технологии интерфейса и серверной части, а для этого нужны разные люди с разными навыками. Если это делает один человек, то скорее всего это будет система без разделения на интерфейсную и серверную часть, а устаревший метод формирования интерфейса на сервере и отдачи браузеру. Варианты написания на разных C# или Delphi вообще не рассматриваются.
Часто бывает так, что программист умеет писать на Python и естественно считает его самым лучшим языком. На Java, Delphi или десятках других. И убеждает заказчика в преимуществах. Это не значит, что нет задач, которые лучше выполнять на тех или иных языках программирования, это действительно так. Но не нужно подгонять проект под язык, который знает тот программист, что попался под руку.
Довольно часто к нам обращаются клиенты, которым какой-то программист написал систему на Java/Python/Delphi и просят эти системы доработать. К сожалению, им будет трудно найти тех, кто согласится это делать. Иногда проще сделать заново, с нуля, на адекватном современном стеке технологий.
Чтобы проверить, будет ли вам легко найти специалиста по тому или иному языку программирования, сравните количество резюме на HeadHunter введя название языка программирования в поисковую строку.
Качество разработки
Качество определяется двумя критериями — архитектура будущего продукта и качество программного кода.
Приведем пример. Первая информационная система написана на шаблонном движке (один из коробочных вариантов распространения, который дорабатывается под нужды клиента). Для того, чтобы получить какие-то данные на экран отправляется запрос на сервер, на сервере включается весь механизм движка, собираются данные для ответа, формируется и выдается браузеру новый интерфейс, который появляется у вас в браузере, когда перезагружается страница. Чтобы что-то доработать, программный код пишется как бы дополняя код движка. Как следствие — система обрастает кодом с каждой доработкой, при этом всякий, кто пишет код, пишет его так, как считает нужным, меняя систему и внося изменения туда, куда считает нужным. Второй пример, сервер и интерфейсная часть системы — это полностью отдельные системы. Интерфейс не перезагружается, а каждый блок информации в интерфейсе, будь то таблица или панель, живут отдельной жизнью. Обмен данными каждый блок интерфейса с сервером выполняет самостоятельно, но при этом этот обмен четко структурирован в соответствии с архитектурой обмена данными между сервером и интерфейсом. Если меняются какие-то данные на сервере, то чтобы они были показаны пользователю, перезагружать страницу не нужно — сервер сам сообщит нужному элементу интерфейса, что данные изменились и передаст их для показа пользователю. Обмен данными производится по определенному протоколу и в соответствии с заранее определенной структурой. На сервере подобные запросы принимаются также в соответствии с архитектурой в определенных точках и обрабатываются по заложенной в системе логике. В такой реализации “наколхозить” или сделать в системе при ее доработке что-то неправильно уже не получится, необходимо писать в соответствии с заложенной архитектурой.
Второй компонент — качество программного кода. Законом программный код приравнен к литературным произведениям (в плане авторства). И как литературное произведение программный код можно написать так, что никто ничего не поймет, а можно логично и стройно. Для каждого языка программирования, да и вообще в программировании, есть общепринятые нормы и стандарты, как для интерфейсных частей, так и для серверных. Например, для языка программирования есть общепринятые мировые стандарты, именуемые PSR (PHP Standart Recommendations). Их много, часть из них принята сообществом к использованию, часть нет. Но суть в том, что профессиональный программист, соблюдающий стандарты и рекомендации, садясь за код, написанный другим человеком может спокойно его поддерживать. Существуют средства разработки, позволяющие проверять код на соответствие стандартам и даже на наличие ошибок (средства автоматизации для разработчиков). Важность соблюдения стандартов переоценить трудно, или это набор непонятного когда, в котором никто не разберется, или это логичный код с понятной архитектурой.
Таким образом, если вы фиксируете в техническом задании стандарты разработки и архитектуру, стек технологий, то снижаете риски последующей полной неподдерживаемости проекта.
Вывод
В индивидуальной разработке программного обеспечения много подводных камней. Выше перечислены только некоторые распространенные риски и проблемы, но следование рекомендациям позволит их существенно сократить.
В первую очередь необходимо четкое подробное техническое задание. В нем должны быть зафиксированы стандарты и подходы. Проект должен быть детальным образом расписан, каждый элемент системы, каждое вычисление. Должен быть дизайн интерфейса. Только после этого можно выбирать вариант, как будет разрабатываться информационная система и кем.
На нашей практике часто встречались случаи, когда заказчику разные специалисты предлагали сделать информационную систему (на основе функционального описания просто с перечислением разделов) за стоимость пары месяцев зарплаты среднего программиста, что сразу вызывает подозрения. После нашего проектирования и просьбы заказчика оценить стоимость разработки по проекту у различных подрядчиков эта стоимость возрастает на порядки, потому что при правильном проектировании и учете в проекте всех нюансов уже не сделать что-то некачественное, упрощенное, а придется делать именно то, что в проекте и соблюдать критерии качества.