Пишем сами Трудности, возникающие при написании корпоративных систем силами программистов предприятия
Вячеслав Ковалев,
tjern@mcsa.ru
Вообще говоря, решиться написать полноценную корпоративную систему, отвечающею всем (или хотя бы большей части) нуждам предприятия, способны только смелые люди. Ведь шаг этот достаточно рисковый. А при создании самой системы программисты обычно наталкиваются на такое количество "подводных камней", что чаще всего сама эта идея затухает в самом начале её реализации.
О том, что лучше - использовать ли готовую систему, лишь настроив её для существующего учета на предприятии (либо наоборот, подстроив сам учет) или заняться разработкой собственной системы, мы спорить не будем. Поговорим лишь о тех, очевидных трудностях, с которыми придется столкнуться в процессе работы над системой. О самых очевидных, ибо на самом деле в каждом конкретном случае, их может быть великое множество, и зависят они от конкретной организации, налаженных или наоборот разлаженных внутренних процессов и даже от личных пристрастий тех или иных руководителей.
Для начала несколько тезисов, исходя из которых обычно и принимаются решения о написание корпоративной системы "внутри" предприятия, а не закупки и настройки готовой. Есть тут как субЪективные, так и обЪективные факторы.
Один из первых факторов (который, может быть, как бы странно это не звучало, быть как субЪективным, так и обЪективным) является то, что существующие на рынке системы не удовлетворяют руководство или конечных пользователей предприятия. Это может быть связано как с тем, что пользователи просто-напросто старается переложить ответственность с себя на программистов. Привыкнув работать в конкретной программе, они не испытывают особого желания обучаться новым навыкам и "просят" чтобы программисты написали что-то похожие, но может быть с улучшенным интерфейсом или с дополнительными, отсутствующими в конкретной сторонней программе, функциями. Конечно, такое далеко не обЪективное мнение, не может служить поводом для начала работ по написанию "внутренней" корпоративной системы, но зачастую случается именно так. Понятно, что прежде чем решиться на такой ответственный шаг, как написание достаточно сложной и требующий больших затрат системы нелишне досконально (насколько это возможно) изучить существующие на рынке предложения. А вот если действительно существующие программные продукты никак не вяжутся с логикой внутренних процессов предприятия, то стоит задуматься о разработке своего продукта. Да и в этом случае, может оказаться более приемлемым тот вариант, когда существующая на рынке система будет доводиться до "ума" после.
Почему так? Хотя бы потому, что пока программисты будут одолевать бастионы программирования, создавая сносную, рабочую версию программы, реализуя пока лишь основные, базовые принципы, та самая программа, от закупки которой отказались в начале может обзавестись необходимым отсутствующим модулем. Тогда возможно придется забросить собственную разработку и приобрести внешний продукт, который к тому же будет уже пригоден к коммерческой эксплуатации, в отличие от неготовой и сырой внутренней разработки. Двойные расходы.
Вообще надо изначально понимать, что разработка и внедрение сложной системы требует достаточно продолжительного времени, которое мерить нужно не месяцами, а годами. Какой бы не были квалификации программисты, разработка столь полномасштабных проектов, как корпоративная система, требует много времени. Пара-тройка лет, как минимум. Поэтому нужно иметь твердую уверенность, что за это время не появиться нужный вам продукт. И не будет ли это дешевле. Конечно, если разработка внутренней системы соизмерима только с зарплатой программистов, то может быть и невелика потеря. Но ведь потраченное время сотрудников - это тоже деньги.
Другой аспект. Часто программу пишут потому, что думают она будет лучше, чем существующие на рынке. Но дело в том, что те программы, которые и есть на рынке - они лучшие. Дело в том, что практически все существующие на российском рынке корпоративные системы имеют корни в таких же кулуарных разработках для конкретного предприятия. Но перед тем как эту систему купите вы, сторонняя программа прошла "откатку" на множестве других предприятий. А вот мучиться с вашей придется вам самим. Учиться дешевле на чужих ошибках.
Теперь о тех "подводных камнях", с которыми придется повоевать программистам. Самый существенный - изначально неверно рассчитанная стратегия написания программы. Может так оказаться, что на каком-то из этапов, окажется, что нужно делать совершенно другую программу. Меняются внешние и внутренние условия. Поэтому перед тем как начать само программирование надо хорошенько позаботиться о том, чтобы структура программы была как можно тщательнее обкатано на бумаге. При этом, даже если в программу нужно будет вносить коренные изменения, сам данный процесс должен быть оговорен еще до начала работы на программой.
Время. При написание больших проектов его нужно много. Желательно - неограниченно. А так как это не реально и понятно, что существуют определенные сроки, то время нужно планировать. Причем жестко и недвусмысленно. И дело не в том, чтобы не выбиться из определенного вначале работ графика. Скорее в том, чтобы выделенное время тратилось именно на то, что было запланировано. Глупо в ходе проекта менять язык программирования или тип сервера баз данных.
Профессионализм. На самом деле может оказаться, что качество написанного проекта будет зависеть не от того насколько профессиональны разработчики, а от верного управления разработкой самого проекта. И это, пожалуй, самый главный "подводный камень" на который наталкивались великолепные команды разработчиков. Программирование больших проектов не имеет никакого отношения к творчеству, это нудный ежедневный монотонный труд, где нужно лишь строго и досконально идти по заранее составленному маршруту. Не многие программисты готовы к этому.
Это конечно не полный перечень возможных проблем при написание больших корпоративных задач. Но мы надеемся, что данную тему продолжим в других статьях.
О том, что лучше - использовать ли готовую систему, лишь настроив её для существующего учета на предприятии (либо наоборот, подстроив сам учет) или заняться разработкой собственной системы, мы спорить не будем. Поговорим лишь о тех, очевидных трудностях, с которыми придется столкнуться в процессе работы над системой. О самых очевидных, ибо на самом деле в каждом конкретном случае, их может быть великое множество, и зависят они от конкретной организации, налаженных или наоборот разлаженных внутренних процессов и даже от личных пристрастий тех или иных руководителей.
Для начала несколько тезисов, исходя из которых обычно и принимаются решения о написание корпоративной системы "внутри" предприятия, а не закупки и настройки готовой. Есть тут как субЪективные, так и обЪективные факторы.
Один из первых факторов (который, может быть, как бы странно это не звучало, быть как субЪективным, так и обЪективным) является то, что существующие на рынке системы не удовлетворяют руководство или конечных пользователей предприятия. Это может быть связано как с тем, что пользователи просто-напросто старается переложить ответственность с себя на программистов. Привыкнув работать в конкретной программе, они не испытывают особого желания обучаться новым навыкам и "просят" чтобы программисты написали что-то похожие, но может быть с улучшенным интерфейсом или с дополнительными, отсутствующими в конкретной сторонней программе, функциями. Конечно, такое далеко не обЪективное мнение, не может служить поводом для начала работ по написанию "внутренней" корпоративной системы, но зачастую случается именно так. Понятно, что прежде чем решиться на такой ответственный шаг, как написание достаточно сложной и требующий больших затрат системы нелишне досконально (насколько это возможно) изучить существующие на рынке предложения. А вот если действительно существующие программные продукты никак не вяжутся с логикой внутренних процессов предприятия, то стоит задуматься о разработке своего продукта. Да и в этом случае, может оказаться более приемлемым тот вариант, когда существующая на рынке система будет доводиться до "ума" после.
Почему так? Хотя бы потому, что пока программисты будут одолевать бастионы программирования, создавая сносную, рабочую версию программы, реализуя пока лишь основные, базовые принципы, та самая программа, от закупки которой отказались в начале может обзавестись необходимым отсутствующим модулем. Тогда возможно придется забросить собственную разработку и приобрести внешний продукт, который к тому же будет уже пригоден к коммерческой эксплуатации, в отличие от неготовой и сырой внутренней разработки. Двойные расходы.
Вообще надо изначально понимать, что разработка и внедрение сложной системы требует достаточно продолжительного времени, которое мерить нужно не месяцами, а годами. Какой бы не были квалификации программисты, разработка столь полномасштабных проектов, как корпоративная система, требует много времени. Пара-тройка лет, как минимум. Поэтому нужно иметь твердую уверенность, что за это время не появиться нужный вам продукт. И не будет ли это дешевле. Конечно, если разработка внутренней системы соизмерима только с зарплатой программистов, то может быть и невелика потеря. Но ведь потраченное время сотрудников - это тоже деньги.
Другой аспект. Часто программу пишут потому, что думают она будет лучше, чем существующие на рынке. Но дело в том, что те программы, которые и есть на рынке - они лучшие. Дело в том, что практически все существующие на российском рынке корпоративные системы имеют корни в таких же кулуарных разработках для конкретного предприятия. Но перед тем как эту систему купите вы, сторонняя программа прошла "откатку" на множестве других предприятий. А вот мучиться с вашей придется вам самим. Учиться дешевле на чужих ошибках.
Теперь о тех "подводных камнях", с которыми придется повоевать программистам. Самый существенный - изначально неверно рассчитанная стратегия написания программы. Может так оказаться, что на каком-то из этапов, окажется, что нужно делать совершенно другую программу. Меняются внешние и внутренние условия. Поэтому перед тем как начать само программирование надо хорошенько позаботиться о том, чтобы структура программы была как можно тщательнее обкатано на бумаге. При этом, даже если в программу нужно будет вносить коренные изменения, сам данный процесс должен быть оговорен еще до начала работы на программой.
Время. При написание больших проектов его нужно много. Желательно - неограниченно. А так как это не реально и понятно, что существуют определенные сроки, то время нужно планировать. Причем жестко и недвусмысленно. И дело не в том, чтобы не выбиться из определенного вначале работ графика. Скорее в том, чтобы выделенное время тратилось именно на то, что было запланировано. Глупо в ходе проекта менять язык программирования или тип сервера баз данных.
Профессионализм. На самом деле может оказаться, что качество написанного проекта будет зависеть не от того насколько профессиональны разработчики, а от верного управления разработкой самого проекта. И это, пожалуй, самый главный "подводный камень" на который наталкивались великолепные команды разработчиков. Программирование больших проектов не имеет никакого отношения к творчеству, это нудный ежедневный монотонный труд, где нужно лишь строго и досконально идти по заранее составленному маршруту. Не многие программисты готовы к этому.
Это конечно не полный перечень возможных проблем при написание больших корпоративных задач. Но мы надеемся, что данную тему продолжим в других статьях.
Комментарии
11