dev.ua продовжує публікацію історії створення IT-Enterprise, найбільш відомої та поширеної української ERP-системи. Про події розказує Володимир Михайлов — один з батьків-засновників компанії. Наступна серія про першу половину 90-х років.
dev.ua продовжує публікацію історії створення IT-Enterprise, найбільш відомої та поширеної української ERP-системи. Про події розказує Володимир Михайлов — один з батьків-засновників компанії. Наступна серія про першу половину 90-х років.
Персоналки щойно перестали коштувати як квартира, ІТ-відділи заводів оголосили їм війну, а ми — двоє програмістів із RAD-суперсилою — раптом опинилися в епіцентрі технологічної революції.
За 1991 рік вартість персональних компʼютерів впала разів в 10, їх почали масово завозити з Кореї. Для директорів промислових підприємств і навіть новостворених компаній купити ПК стало справою престижу, яку вони могли собі дозволити.
І тут ми витягнули ще один щасливий квиток, який був у ставленні 90% ІТ-відділів великих підприємств до цієї техніки. На кожному промисловому підприємстві вже працювали інформаційно-обчислювальні центри з великими ІТ-відділами, які роками писали програми на PL/1, COBOL, Fortran… Написано було багато, усе це треба було підтримувати, а переходити на нові технології — ні часу, ні бажання. Тому персоналки вони сприйняли «в штики»: це, мовляв, несерйозні цяцьки, а справжні програмісти працюють лише на мейнфреймах.
Для нас це було Бінго!!! Джекпот!!! Бо ми вміли програмувати на «цяцьках» і знали потреби промислових підприємств. Можна було заходити і укладати договори на розробку практично без конкуренції.
Рефлексуючи на ці роки, я бачу, що це була розробка окремих задач для клієнта. Наприкінці проєкту було приблизно так: «Зробили, дякуємо, до побачення». Чому так? Ми працювали з промисловістю, яка вже мала великі автоматизовані системи управління і нам замовляли тільки ті задачі, яких в них не вистачало, в основному по управлінню виробництвом. Мейнфрейми ще працювали, відділи АСУ теж працювали і всіма руками трималися за «теплу трубу рідного заводу». Дуже показовою була робота з Донецьким заводом холодильників NORD. Після обстеження і пропозиції розробити для них систему управління виробництвом і техніко-економічного планування на мережі персональних ЕОМ, нас звідти виштовхнули саме колеги-айтівці, після того, як керівник відділу
АСУ зрозумів, що всіх його «50-річних дівчат»-операторів ЕОМ треба буде просто звільнити через непотрібність, «а він з ними життя прожив». Тому ми й хапалися за розробку всього, що завгодно.
Через 5-7 років у кількох замовників поступово ми забрали всі задачі управління, реалізувавши їх на мережі персональних комп’ютерів. «Раптом» з’ясувалося: мейнфрейми більше не потрібні. Усе, що на них працювало, ми уже паралельно запускали на нових платформах. Кінець для «динозаврів» настав невідворотно — розформування старих ІТ-відділів, звільнення, набір нових фахівців. Ігнорувати технічний прогрес смерті подібно! Але це було потім…
Коли наступили 1992 і 1993 роки, рухнула планова економіка, а ніякої іншої ще не було. Промисловість зупинялася, масові невиплати зарплати, безробіття, шалена інфляція, яка підстьобувалася популістськими рішеннями влади. Фактично за ці два роки припинили існувати
більшість київських наукових інститутів, зокрема Інститут кібернетики на Теремках фактично збезлюднив, тому що не було державних замовлень «на науку», а київський військово-промисловий комплекс просто перестав існувати.
До речі, саме в цей рік вперше я запримітив молодого Віктора Ющенка, який стоячи на трибуні Верховної Ради просто орав на депутатів, намагаючись до них донести, що закон про індексацію всіх зарплат і соціальних виплат, який вони затверджували в N-й раз поспіль призведе тільки до ще більшого зубожіння населення. Але закон в N-й раз прийняли і інфляція сягнула 1000% на рік. В таких умовах заключені на початку року договори на розробку вже у квітні були варті декількох кілограмів мʼяса. Тобто гроші переставали бути грошами і в економіці запанував «бартер». Ми здавали проєкт, а нам у відповідь: «Грошей нема. Можемо розрахуватися продукцією».
Жах! І що з цією їхньою продукцією робити? Ми ж програмісти, а не торговці. Так, наприклад, Донецький завод холодильників розрахувався з нами своїми холодильниками «Донбас». Один з них працював в мене вдома років 15. Радомишлянська швейна фабрика за проєкт обліку в виробництві розрахувалася кількома центнерами постільної білизни. Її було стільки, що наші родини користувалися цим наступні років 20. Тоді ніхто навіть не міг уявити на те, що нас чекає попереду і яка доля буде у цієї білизни.
У серпні 2014 року, коли стався Іловайськ, ми з дружиною включились у волонтерський рух, приїхали в Головний військово-клінічний госпіталь на Лесі Українки у Києві й запитали що потрібно. Головний лікар хірургічного відділення написав список всіляких ліків, які ми скупили в аптеках, і завезли в госпіталь. Зненацька лікар сказав, що якщо є стара постільна білизна, то можете привезти — не вистачає. І тут ми зрозуміли, що в нас дома через 20 років після розрахунку за проєкт автоматизації початка 90-х ще залишалось кілограмів 25 зовсім нових простирадл, підковдр і наволочок. Все це ми й привезли в госпіталь — лікарі були шоковані та розплакалися від такого багатства.
Чим тільки з нами не розраховувались на початку 90-х. І кабелем, і люстрами, і м’ясом…. Зараз смішно, але то були такі часи, і такі «гроші».
Падіння цін на ПК дозволило нам купити другий комп’ютер і брати більше робіт. У ці роки ми хапалися за всі запити клієнтів. Маючи RAD систему розробки, можна було все це виконувати вчасно і заробляти непогані гроші. Озираючись назад, бачу, що такі проєкти дозволили вибудувати
повноцінну технологію швидкого створення програмних продуктів і практично крок за кроком охопити всі можливі задачі управління на підприємствах.
Декілька років пройшло в захваті від можливості надшвидко, в уявленні тих років, розробляти все що завгодно і запускати у клієнта. Від спостерігання того, як клієнти користуються твоїм софтом, я відчував справжнє задоволення.
Чи виникали в голові якісь сумніви, чи правильно я все це роблю і займаюсь тією справою, про яку мріяв з дитинства? З урахуванням того що ми забезпечили собі доходи в разів 20 більше, ніж наукові співробітники навколо нас, що сиділи поряд на четвертому поверсі 18 корпусу КПІ, то ні. В голові сиділа думка «я ж мріяв бути програмістом, ось я і став програмістом, тобто я розробляю програми й задовольняю клієнта — пишу для нього те, що потрібно саме цьому клієнту. І це приносить неабиякий дохід. Все вірно».
Так і в світі панувала саме така думка — розробка під замовлення кожного клієнта. Саме так починав і SAP — батьки-засновники якого працювали в європейському відділенні IBM і створювали під кожного замовника софт.
Поступово, десь у віці 27-28 років мені стало набридати писати програми. До цього моменту вже опанував 11 мовами програмування від двох асемблерів IBM і DEC, через всі стандартні мейнфреймовські мови до GPSS, StamClass, Pascal, C, Natural, Clipper, Foxpro, …. Робити десять разів поспіль одне й те саме, але з різним синтаксисом? Далі було вже не так цікаво…
Я завжди ставив собі питання, а що буде через 5-10 років? Що буде через рік вже не турбувало, зрозуміло, що буде те саме, що і зараз, але, мабуть, трохи більше…
За кілька років клієнти і, навіть колеги, почали рекомендувати нас своїм знайомим і у нас не було відбою від замовлень. Потрібно було розширюватись і залучати фахівців.
На жаль, а тепер розумію що і на щастя, абсолютна більшість молодих фахівців і студентів старших курсів компʼютерних спеціальностей ФІОТ КПІ, яких ми запрошували на роботу, були фантастично обдарованими програмістами, але з мінімальними навичками спілкування з замовниками. Якщо для мене ніколи, навіть у 23-річному віці, не було ніяких проблем в спілкуванні з замовниками (приїхати на величезне підприємство й обстежити предметну область спілкуючись з багатьма керівниками різних служб, погодити й відстояти свої рішення, підписати технічні документи, здати замовнику проєкт, витримавши водночас «звичайний мордобій при прийомці», провести навчання користувачів…), то абсолютна більшість молодих програмістів тремтіли, потіли, непритомніли і… врешті-решт звільнялися від однієї тільки думки про перспективу спілкування з
«товстими дядьками-замовниками». Тому під час набору нових програмістів, прийшлося всі ці роботи взяти на себе.
За ці роки ми швидко зрозуміли, що треба не самим з Олегом Щербатенко писати всі програми самотужки, а спеціалізуватись і виконувати ролі керівників проєктів, бізнес-аналітиків, проєктувальників. При умові нормально розписаних постановок задач на програмування від нас,
програми можуть писати і «чисті програмісти», які взагалі не хотіли розуміти предметної області й навіть пишалися цим. Для цього треба впроваджувати стандарти програмування, типізувати інтерфейси і взагалі уніфікувати схеми обробки інформації. Цим досягалася повна замінність
програмістів, абсолютна типовість інтерфейсів по всіх програмах і мінімізувався час навчання як і нових програмістів, так і кінцевих користувачів.
Суперефективність досягалася ще й тим, що, проєктуючи нові задачі, я розумів до останніх команд програми, як це повинно бути написано, тобто найкваліфікованіший програміст став бізнес-аналітиком і проєктував те, що треба запрограмувати, розуміючи, як це зробити в деталях.
На цьому етапі змінилася моя роль — тепер вже не програміст, а керівник проєктів, проєктувальник і найбільш кваліфікований розробник. Зараз це назвали б PM-ом, архітектором, тімлідом, теклідом, бізнес-аналітиком і сіньйором в одному флаконі, але на початку 90-х все було простіше.
Термін RAD (Rapid Application Development), який зʼявився в той час з легкої руки Джеймса Мартіна в його суперпопулярній книзі тих років «Принципи розробки програмного забезпечення», був показово повно реалізований в ті роки в FoxPro 2.0, який став нашою основною платформою, і ще в декількох платформах таких як PowerBuilder, Delphi…
І якщо на початку 90-х програмісти навколо, що мали найбагатший досвід програмування на попередніх платформах, намагалися писати в старому стилі, а ми користувалися тим, що могли за допомогою RAD розробляти софт мінімум в 10 разів бистріше, то вже за кілька років всі навколо
освоїли новий інструментарій і наша конкурентна перевага поступово випарувалася. Треба було чимось відрізнятися від інших. Але про це в наступній серії.
Проводячи аналогії з початком 2026 року, з ейфорією від AI-фреймворків для розробки ПЗ, що з’явилися останніми місяцями, та гаслом «програмісти не потрібні», передбачаю: цю нову спіраль розвитку ІТ-спільнота опанує за кілька років, що призведе до глобальних змін у структурах ІТ-компаній.
Водночас зникнуть ті ІТ-компанії, що пропустять цей новий виток розвитку. Найімовірніше, це станеться не одразу: вони залишаться підтримувати старі рішення, але згодом усе ж таки зникнуть. А аргументи «досвідчених розробників», які є гуру вчорашніх технологій, будуть такими самими, як і 30 років тому: «це не програмування, а хтозна-що», «я не можу відповідати за код, який я сам не написав, це якась дурня», «у цьому коді бракує певних можливостей, які є в нашому старому коді, а замовникам потрібні саме ці можливості-бантики»… І ще безліч таких «аргументів», яких ринок уже не прийме.
У 2026 чекаю пертурбації і зміни ринку.
