Труднощі, що виникають при написанні корпоративних систем силами програмістів підприємства, Комерція, Різне, статті

Взагалі кажучи, зважитися написати повноцінну корпоративну систему, що відповідає всім (або хоча б більшої частини) потребам підприємства, здатні тільки сміливі люди. Адже крок цей досить ризиковий. А при створення самої системи програмісти зазвичай натрапляють на таку кількість “підводних каменів”, що найчастіше сама ця ідея згасає на самому початку її реалізації.

Про те, що краще – чи використовувати готову систему, лише налаштувавши її для існуючого обліку на підприємстві (або навпаки, подстроив сам облік) або зайнятися розробкою власної системи, ми сперечатися не будемо. Поговоримо лише про тих очевидних труднощі, з якими доведеться зіткнутися в процесі роботи над системою. Про найбільш очевидних, бо насправді в кожному конкретному випадку їх може бути безліч, і залежать вони від конкретної організації, налагоджених або навпаки розладнаним внутрішніх процесів і навіть від особистих пристрастей тих чи інших керівників.

Для початку кілька тез, виходячи з яких зазвичай і приймаються рішення про написання корпоративної системи “всередині” підприємства, а не закупівлі та налаштування готовою. Є тут як суб’єктивні, так і об’єктивні фактори.

Один з перших факторів (який, може бути, як би дивно це не звучало, бути як суб’єктивні, так і об’єктивних) є те, що існуючі на ринку системи не задовольняють керівництво або кінцевих користувачів підприємства. Це може бути пов’язано як з тим, що користувачі просто-напросто намагаються перекласти відповідальність з себе на програмістів. Звикнувши працювати в конкретній програмі, вони не відчувають особливого бажання навчатися новим навичкам і “просять”, щоб програмісти написали щось схоже, але, може бути, з поліпшеним інтерфейсом або з додатковими, відсутніми в конкретній сторонньої програмі, функціями. Звичайно, таке далеко необ’єктивне думка не може бути приводом для початку робіт з написання “внутрішньої” корпоративної системи, але часто трапляється саме так. Зрозуміло, що перш ніж зважитися на такий відповідальний крок, як написання досить складною і вимагає великих витрат системи, не зайве досконально (наскільки це можливо) вивчити існуючі на ринку пропозиції. А от якщо дійсно існуючі програмні продукти ніяк не в’яжуться з логікою внутрішніх процесів підприємства, то варто задуматися про розробку свого продукту. Та й у цьому випадку може виявитися більш прийнятним той варіант, коли існуюча на ринку система буде доводитися до “розуму” після.

Чому так? Хоча б тому, що, поки програмісти будуть долати бастіони програмування, створюючи стерпну, робочу версію програми, реалізуючи поки лише основні, базові принципи, та сама програма, від закупівлі якої відмовилися на початку, може обзавестися необхідним відсутнім модулем. Тоді, можливо, доведеться закинути власну розробку і придбати зовнішній продукт, який до того часу буде вже придатний до комерційної експлуатації, на відміну від неготовою і сирої внутрішньої розробки. Подвійні витрати.

Звичайно, треба спочатку розуміти, що розробка та впровадження складної системи потребує досить тривалого часу, який міряти потрібно не місяцями, а роками. Якою б не були кваліфікації програмісти, розробка настільки повномасштабних проектів, як корпоративна система, вимагає багато часу. Пара-трійка років, як мінімум. Тому потрібно мати тверду впевненість, що за цей час не з’явитися потрібний вам продукт. І чи не буде це дешевше. Звичайно, якщо розробка внутрішньої системи порівнянна тільки із зарплатою програмістів, то, може, й невелика втрата. Але ж витрачений час співробітників – Це теж гроші.

Інший аспект. Часто програму пишуть тому, що думають вона буде краще, ніж існуючі на ринку. Але справа в тому, що ті програми, які і є на ринку – вони найкращі. Справа в тому, що практично всі існуючі на російському ринку корпоративні системи мають коріння в таких же кулуарних розробках для конкретного підприємства. Але перед тим як цю систему купите ви, стороння програма пройшла “відкатку” на множині інших підприємств. А от мучитися з вашою доведеться вам самим. Вчитися дешевше на чужих помилках.

Тепер про тих “підводних каменях”, з якими доведеться повоювати програмістам. Найістотніше – спочатку невірно розрахована стратегія написання програми. Може так виявитися, що на якомусь з етапів виявиться, що потрібно робити зовсім іншу програму. Змінюються зовнішні та внутрішні умови. Тому перед тим, як почати саме програмування, треба гарненько подбати про те, щоб структура програми була якомога ретельніше обкатана на папері. При цьому, навіть якщо в програму потрібно буде вносити докорінні зміни, сам цей процес повинен бути обговорений ще до початку роботи на програмою.

Час.

При написанні великих проектів його потрібно багато. Бажано – необмежено. А так як це нереально, і зрозуміло, що існують певні строки, то час потрібно планувати. Причому жорстко і недвозначно. І справа не в тому, щоб не вибитися з певного спочатку робіт графіка. Швидше в тому, щоб виділений час витрачалося саме на те, що було заплановано. Нерозумно в ході проекту змінювати мову програмування або тип сервера баз даних.

Професіоналізм.

Насправді може виявитися, що якість написаного проекту буде залежати не від того наскільки професійні розробники, а від вірного управління розробкою самого проекту. І це, мабуть, самий головний “підводний камінь”, на який наштовхувалися чудові команди розробників. Програмування великих проектів не має жодного відношення до творчості, – це нудний щоденний монотонна праця, де потрібно лише строго і досконально йти по заздалегідь складеному маршруту. Небагато програмісти готові до цього.

І це звичайно не повний перелік можливих проблем при написанні великих корпоративних завдань.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*