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