Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

(Не) успішність IT-проектів та чинники які на неї впливають

Стретегія бізнесу та роль IT проектів

Наш світ зараз перебуває у стані четвертої промислової революції, яка трансформує цифрові технології та поєднує фізичний, біологічний, хімічний та інформаційні світи. У зв’язку з цим сильно зростає роль IT у житті абсолютно будь-якого бізнесу, який для того, щоб вижити, він повинен пройти шлях цифрової трансформації, тобто здійснити перехід на цифрові технології, які стають основою для нових товарів та послуг, нових методів роботи та нових бізнес-моделей.

Основним (але не єдиним) джерелом прибутку для бізнесу (отримання якого є однією із цілей його ведення) та його капіталізації є операційний потік готівки — виручки, яку приносить компанії її безпосередня діяльність. Оскільки в будь-якій компанії існують кінцеві споживачі, кількість яких обмежена, і вона практично ніколи не працює в сегменті ринку одна, у конкурентів необхідно забирати максимально можливий операційний потік готівки. Це завдання досягається шляхом визначення та реалізації стратегії бізнесу. Інакше кажучи, якщо мета бізнесу — економічні, соціальні чи інші прагнення, заради яких існує підприємство, то стратегія бізнесу — це єдиний набір планів та дій, спрямованих на досягнення основних цілей бізнесу організації. Частиною стратегії бізнесу є стратегія IT.

Розробка стратегії IT — важливий та складний процес, який має відповісти на головне питання: як має змінитися архітектура ІТ відповідно до архітектури (моделі) бізнесу, яка, у свою чергу, коригується з метою досягнення нових вимог бізнес- та функціональних стратегій.

Напрями розвитку ІТ мають бути повністю інтегровані з напрямками розвитку бізнесу.

У зв’язку з цим компанії пробують автоматизувати свої процеси за допомогою ERP систем, розробляють сайти та мобільні програми та створюють у собі цілі IT департаменти. Але, незважаючи на це, багато ініціатив закінчуються негативно і компанії залишаються біля розбитого корита. Чому так відбувається? Причин цьому кілька і в цій статті я хочу поговорити про фактори успішності IT проектів та наведу кілька прикладів зі своєї практики участі у впровадженнях ERP Odoo, коли проекти закінчувалися неуспішно та проаналізую причини таких провалів.

Існує безліч статистик щодо успішності проектів і як показує практика, яку з них не візьми статистика невтішна, більшість проектів заканчуються неуспішно, а у тих проектів, які закінчуються успішно, статті витрат на їх завершення стрімко роздмухуються, при цьому іноді в кілька разів. При цьому якщо проект навіть завершується і його мети начебто досягнуто, замовник все одно може бути чимось незадоволеним. І тут можна відзначити першу причину неуспішності проектів, що завершуються, — замовник сам не знає чого хоче, а якщо про щось говорить, то не факт, що те, що він говорить дійсно йому потрібно. Або ж він може випустити якусь деталь, без якої він не зможе наприклад працювати, а потім, коли проект уже добігає кінця, він запитує: «а де ж? я без цього не зможу працювати. Це ж зрозуміло, що це має бути». І тут у провалі проекту більше буде винуватий сам замовник, ніж виконавець.

У процесі ведення проекту задіяно кілька ролей: проектний менеджер, бізнес-аналітик та розробник. При цьому кожен із них відповідає за свою ділянку: проектний менеджер контролює перебіг проекту, бізнес-аналітик визначає межі проекту, а розробник відповідає за технічну реалізацію.

Роль бізнес-аналітика в IT проекті і чому без нього не обійтися

Як показує практика, замовник не так погано реагує на зростання обсягу проекту, як на зростання його вартості. Тут усе зрозуміло — він же за ті гроші планує отримати більше, а для проекту це не дуже добре, оскільки це знижує рентабельність проекту (якщо такий проект виконується зовнішнім виконавцем).

Для усунення такого ризику дедалі більше зростає роль бізнес-аналітика, який є буфером між клієнтом та командою розробки. При цьому бізнес-аналітик повинен добре розбиратися в менеджменті, вміти аналізувати бізнес-клієнта, на основі цього аналізу давати клієнту поради, думати категоріями «Що потрібно бізнесу» та «Навіщо йому це потрібно», і лише потім відповідати на запитання «Як це буде реалізовано». Тобто він оперує бізнес-вимогами. Ось тут для замовника настає колапс головного мозку. Дуже часто часом замовники не розуміють, навіщо їм бізнес-вимоги, а хочуть відразу опис функціональних вимог.

Тут одразу ж порушується цілісність проекту та виникає ризик того, що замовник отримає не те, що намалював у своїй голові.

На жаль для багатьох IT компаній роль бізнес-аналітика знівельована і якщо він навіть присутній у проекті, то лише для того, щоб малювати схеми процесів або стенографувати потік думок клієнтів, який потім передається розробникам, які починають пиляти щось, що може і не потрібне клієнту. Тому дуже велике поширення набувають методології, на кшталт SCRUM, які дають результат, але на які потрібно витратити більше часу та грошей.

Але якщо подивитися на визначення, хто ж такий бізнес-аналітик, у тій самій вікіпедії, то:

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

Міжнародний Інститут Бізнес-Аналізу (IIBA, International Institute of Business Analysis) визначає бізнес-аналітика «як посередника між зацікавленими особами для збору, аналізу, комунікування та перевірки вимог щодо зміни бізнес-процесів, регламентів та інформаційних систем. Бізнес-аналітик розуміє проблеми та можливості бізнесу в контексті вимог та рекомендує рішення, що дозволяють організації досягти своїх цілей».

У консалтинговому бізнесі бізнес-аналітиком називається найвища позиція для консультанта.

Як ми бачимо, що бізнес-аналітик це все ж таки більше про менеджмент, ніж про IT.

Бізнес-аналітик професія яка теж у свою чергу має безліч відгалужень (якщо наприклад говорити про розробку якого-небудь продукту). Наприклад, можна виділити:

  • Власника продукту (Product Owner) — проектна роль, відповідальна за збір вимог до продукту, документування вимог у формі історій, завдання пріоритету історіям і приймання функціональності, реалізованої командою.
  • Бізнес-аналітика, фахівця, який мислить категоріями — «що» та «навіщо» і який визначає бізнес-потребу клієнта.
  • Системного аналітика — фахівця, який аналізує потреби клієнта щодо можливості їх задоволення за допомогою функцій відповідної інформаційної системи. Також його часто називають «постановником завдань». Основним продуктом такого системного аналітика є організаційно-технічні рішення, що оформлюються як технічне завдання (або окремі завдання) на систему чи програмне забезпечення.
  • Бізнес-тренер — спеціаліст, який займається навчанням користувачів роботі в системі.
  • Архітектора бізнесу (бізнес-архітектор) — це людина, яка ініціює створення нових бізнес-підприємств, веде за собою архітектурні інновації бізнесу, проектує передові бізнес-моделі та створює стійкі збалансовані бізнес-системи, орієнтовані на довгостроковий успіх. Але ця роль трапляється дуже рідко.

Залежно від обсягу проекту ці ролі можуть виконуватися однією людиною або виділятися окремо.

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

Головне завдання бізнес-аналітика — виявити проблеми бізнесу замовника та знайти максимально ефективне рішення. Для цього він повинен мати знання в предметній галузі. Бізнес-аналітик працює з вимогами на всіх етапах життєвого циклу розробки ПЗ та постійно виступає посередником між замовником та командою програмістів.

При цьому бізнес-аналітик не повинен лізти в технічну частину рішення, а донести до розробників (або до системного аналітика) бізнес-потребу.

Проектний трикутник

Основне завдання бізнес-аналітика — визначити межі проекту, тобто його scope, тобто обсяг робіт. Усі ми пам’ятаємо знаменитий трикутник проекту

Умовно його ідею можна сформулювати в один рядок:

«Швидко — Якісно — Дешево: виберіть будь-які два пункти».

З цього виходить:

  • хочеться швидко та якісно — буде дорого;
  • потрібно дешево та якісно — буде довго;
  • потрібно швидко і дешево — буде, очевидно, неякісно.

Всі ці величини мають верхні межі:

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

Внесення змін до однієї із сторін трикутника змінює щонайменше ще одну пов’язану сторону.

Нематеріальність вихідної продукції проекті автоматизації створює ілюзію те, що для внесення зміни до списку вимог чи вже реалізовані вимоги потрібні незначні зусилля. Це помилка! Для розуміння можна наводити аналогію з будівництвом і зносом і переробкою цегляної стіни, якщо її потрібно зрушити, наприклад, на 15 см. «Цеглики» коду системи теж потрібно розібрати та перенести — нехай це не фізичні, а розумові зусилля виконавців, але час це займає , як і перекладка цегли.

Це, як показує моя практика, дуже велика проблема в таких проектах. Якщо замовник на початковій стадії проекту не знає, що йому точно потрібно, то потім він може захотіти щось абсолютно протилежне зі словами: «Я це й мав на увазі» або «Я без цього не можу працювати. Без цього ваша система мені не потрібна»

Далі у такому трикутнику проявляється конфлікт інтересів замовника та виконавця:

Цілі замовника проекту: зробити більше (збільшити обсяг робіт), швидше (строки скоротити), дешевше (менше ресурсів потрібно).

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

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

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

Тепер поговоримо про чинники успішності проекту.

Чинники ( не) успішності проекту

Для того, щоб ваш IT проект завершився успішно і щоб сильно не виходив за рамки спочатку певного трикутника проекту, необхідно контролювати кілька факторів, які сильно впливають на успішність проектів.

Чинник успіху № 1. Підтримка керівництва

Напевно, це найвпливовіший чинник на успіх проекту. Якщо керівники з боку замовника не підтримують проект, то вони на нього неохоче виділятимуть ресурси — свій час, гроші. Вони його неохоче захищатимуть, якщо в ході проекту щось піде не так. Співробітники бачачи, що керівництво неохоче підтримує проект, теж можуть ставитися до нього прохолодно і навіть шкодити проекту.

Чинник успіху № 2. Залучення користувачів

Цей фактор хоч і стоїть на другому місці, але за своїм значенням такий самий впливовий. І тут я хочу розповісти історії зі своєї практики впровадження ERP Odoo, яка закінчилася неуспішно (були звісно і вдалі проекти, але невдалих було трошки більше).

Приклад 1

Клієнта зацікавила ERP система, впровадженням якої займалася наша компанія. Під цей проект було виділено команду бізнес-аналітиків, які зібрали вимоги і на підставі цих вимог було доопрацьовано систему. Потім почалося навчання співробітників, які під час навчання згенерували нові вимоги, які також були реалізовані. Після першого навчання минуло кілька місяців, співробітники природно все забули і замовник попросив провести навчання співробітників з ролей: менеджер із закупівлі, менеджер із продажу, бухгалтер. Це навчання також було проведено, результатом навчання були персональні інструкції по роботі в системі, які зробили самі співробітники. І начебто все було гаразд, але після завершення навчання нічого не сталося — співробітники відмовилися працювати в системі. Чому? відповіді це питання немає досі. Але в ході цього проекту виявилася ще одна типова проблема пов’язана з користувачами: вони дуже важко відмовляються від систем, де працювали досі. І не важливо, що це за система: це може бути звичайна Excel або 1с, або взагалі якась самописна система.

У зв’язку з цим виникають вимоги, які не можна реалізувати чи реалізувати дуже складно.

Приклад 2

Тут хочу навести приклад вже з іншого проекту. Замовник замовив комплексну ERP-систему, яка охоплює майже всі його процеси. До цього він працював у ряді застарілих систем, які він захотів замінити на одну. Першою перепоною і причиною затягування термінів стала погана робота бізнес-аналітика, які збирав вимоги щодо низки основних сегментів (маркетинг, crmі продажу) в режимі стенограми. Потім ці вимоги потрапили до мене як до системного аналітика, які були оброблені і на їх основі програмістам було поставлено низку завдань. Після реалізації система почала показуватися клієнту, який почав говорити, що це не що ми чекали. У відповідь ми почали говорити, що ось у вимогах написано так — так і зроблено. І тут прийшло одкровення — замовник почав говорити, що ми не орієнтуємося на цей документ, він написаний незрозумілою для нас мовою. Після чого почалося уточнення вимог, що спричинило додаткові витрати з нашого боку, які природно ніхто не компенсував.

Одним блоком (Фінанси) з цих вимог займався я, починаючи від їхнього збору і закінчуючи реалізацією в системі, і я чітко знав, що все, що було потрібно, — реалізовано. І тут після демонстрації реалізації вимог виник новий закидон з боку клієнта: «Нам цим незручно користуватися. Ось дивіться, як у нас це відбувається зараз у нашій програмі» і відкриває переді мною дуже стару програму з допотопним інтерфейсом, яка призначена виключно для обліку коштів. «Ось дивіться як швидко я це роблю тут, а як довго робитиму там». Хоча у нас повноцінна облікова система, з повноцінним обліком заборгованостей, рухом коштів тощо. Ще одним відкриттям стало для мене те, що ні головний бухгалтер ні фінансовий директор не оперував рахунками обліку та проводками. Як вони збиралися робити таку форму звітності, як «Баланс», для мене загадка.

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

По-перше, користувачі зазвичай не дуже розуміються на IT. І часом від них можуть виходити вимоги, які складно реалізуються або не реалізуються взагалі (наприклад — самостійне створення нових об’єктів). При цьому ці вимоги можуть змінюватися по ходу проекту. Сьогодні хочу ось так, а завтра вже інакше. А як воно впливає на суміжні сегменти системи, мало кого хвилює.

По-друге, вимоги від користувачів можуть зростати постійно, навіть коли процес впроваджується. І чим складніше впроваджувана система, тим складніше внести до неї зміни.

Якщо ж користувачів не залучати до збору вимог, то вони потім скаржаться на те, що їхні думки не допитувалися і вони не користуватимуться цим.

З погляду користувачів, співробітники IT департаменту чи компанії часто приходять до них, задають два-три питання і йдуть кудись на пару місяців, а потім приносять якесь рішення, яке їх як користувачів не влаштовує, навіть якщо там справді реалізовано всі необхідні функції.

Усунути цю проблему складно, але можливо. Тут можна дати таку рекомендацію: залучайте користувачів раніше, але за допомогою добре продуманого керованого процесу. Знайдіть експерта у певній галузі і працюйте з ним. Визначте конкретні результати їхньої участі та «висікайте вимоги в камені», тоді вдасться уникнути роздмухування масштабів.

Тому тут особливу роль відіграють правильно сформульовані вимоги до системи, а це процес непростий, важковитратний, але такий, що стоїть, як кажучи «овчинка варта вичинки».

І спробуйте визначити критерії приймання з боку користувачів.

Чинник успіху 3: досвідчений керівник проекту

На успішність проекту також сильно впливає керівник проекту (про нього я вже згадував вище).

Керівник проекту (менеджер проекту, project manager, PM) — це спеціаліст, який відповідає за успішне виконання проекту: у зазначені замовником терміни, з необхідною якістю, при фіксованому бюджеті, обмежених людських ресурсах та відповідно до вимог замовника. Найчастіше це адміністративний керівник функціональної проектної групи, який забезпечує оперативне керівництво та контролює здійснення робіт, які проводяться в рамках проекту. В умовах постійного посилення конкуренції особливо актуальними стають готовність компанії до непередбачених поворотів подій та здатність грамотних менеджерів передбачати, планувати та керувати змінами. У бізнесі робота за проектом є свого роду мистецтвом і потребує умінь, часу та сил. Щоб проект став успішним, керівник проектів забезпечує:

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

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

Також звичайно бажано контролювати бюджет проекту та його рентабельність. Навіщо вам проекти, що працюють у мінус?

Чинник успіху 4. Чітко визначені цілі проекту

Це перший фактор, який не пов’язаний з людським фактором. І хоча всі про цей фактор знають, але більшість проектів, які запускаються, не мають чітко визначених цілей.

Це дуже схоже на ставлення всіх до ранкової гімнастики — усі визнають, що робити треба, але ніхто не робить.

Відмовок теж ціла купа. То ліньки, то якісь організаційні чинники, то жорсткі терміни, а то й реструктуризація компанії.

Але, подумайте, якщо ви не знаєте навіщо вам наприклад ERP-система і які завдання вона повинна вирішувати, чи отримаєте ви в результаті, то що вам потрібно. Найбільший інтерес для визначення цілей проекту має замовник проекту. І якщо він сподівається, що команда виконавців сама щось вигадає і зробить і він отримає те, що потрібно. Ну ну...... Напишіть мені про результати такого підходу.

Чинник успіху 5. Чітко визначений (і зменшений) обсяг робіт

Цілком очевидно, що чим більший термін виконання проекту, тим менша ймовірність того, що його буде завершено успішно. Цілі проекту визначають його обсяг. Звідси висновок, якщо немає цілей, то обсяг проекту можна сказати безмежний.

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

Тут менеджер проекту повинен розуміти, що за певну кількість часу можна виконати певний обсяг робіт. Якщо приймається рішення задіяти додаткові ресурси (тобто людей), необхідно пам’ятати, що чим більше людина бере участь у вирішенні проблеми, тим довше вона вирішуватиметься. І тут не діє правило: чим більше людей задіяно, тим швидше зробиться. В книзі Фредеріка Брукса «Міфичний людино-місяць, або як створюються програмні системи» (сподіваюсь переклав правильно) сформульований закон Брукса «Якщо проект не укладається у строки, то додавання робочої сили затримає його ще більше». Можна ще навести улюблену керівниками проектів цитату, коли потрібно це все обґрунтувати в одному реченні: «Навіть якщо зібрати разом 9 вагітних жінок, то дитина через місяць не народиться».

Всі ми знайомі з таким мемом:

У житті так і відбувається.

Зазвичай, єдиним шляхом зменшити час роботи над проектом — обмежити його обсяг. У багатьох випадках є сенс розбити проект на маленькі та короткострокові проекти.

Чинник успіху 6. Більш короткострокове планування, велика кількість контрольних точок.

Як ви зрозуміли смертельним ворогом успішності проекту є час. Тому вас не має здивувати цей фактор. Великі проекти зазвичай ділитися на віхи.

Віхи проекти — своєрідні маркери, які допомагають рухатися за планом проекту і вказують на важливі важливі етапи або події. Це можуть бути фази проекту, перехідні точки, в яких повинні бути зібрані зовнішні дані, ресурси або рішення або просто контрольні точки. Чим частіше ви намічаєте контрольні точки, тим успішнішим буде ваш проект, тим раніше ви помітите, що проект пішов не туди і тим більше у вас буде часу на коригування курсу проекту. Але не перестарайтеся, занадто багато таких точок демотивуватиме вашу команду.

Чинник успіху 7. Чітко визначений процес управління проектом.

Отже, «більше часу, більше грошей і більше людей» — це не запорука успіху проекту. Головними чинниками успіху буде залучення до роботи потрібних людей та чітке визначення ключових елементів проекту.

Досвідчений менеджер проекту вже володіє технологією успішного ведення проекту, якщо ж ні, то, ймовірно, ваш менеджер проекту не контролює проект, а якщо цього не робить він, то як правило не робить ніхто. Якщо ви чуєте від менеджера проекту — я не контролюю проект, то можете такий проект вже поховати.

Процес управління проектом має бути максимально простим та чітко визначеним. Якщо процес змінюється щодня, це вводитиме сумбур і незрозумілість. Тут може допомогти розробка та впровадження регламентів, але це не так просто, як здається. Наявність регламенту не гарантує його виконання.

І пам’ятайте, що процес заради самого процесу — марна трата часу. Добре певний процес управління проектом не позбавить всіх проблем, але може знизити рівень помилок і повторної роботи наполовину, що може заощадити значну частину вартості проекту.


Висновки

Сучасний бізнес постійно знаходиться в пошуку конкурентних переваг, які дадуть йому можливість вижити на ринку та розвиватися. Одним із чинників успішності бізнесу є застосування ним IT технологій і якщо воно увінчалося успіхом, то він уже має перевагу перед конкурентами. Саме тому бізнес знаходиться у пошуку рішень, які структурують його роботу або дадуть йому «фішку» якої немає у конкурентів.

Більшість проектів, які ініціюються бізнесом, закінчуються невдачею, причин тому безліч. Аналіз цих причин призвів до факторів, які необхідно контролювати і вчасно сигналізувати про негативні тенденції.

Якщо ви починаєте якийсь проект, наприклад впровадження у себе ERP-системи, пам’ятайте про те, що успіх такого проекту здебільшого залежить в основному від вас, а не від підрядника якого ви наймете для його виконання.

А що скажете ви з цього приводу? Що спричинює невдачі у IT проектах і як їх можна уникнути?

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Тут одразу ж порушується цілісність проекту та виникає ризик того, що замовник отримає не те, що намалював у своїй голові.

Велике питання що намалює аналітик

А може бути все простіше, в мене знайомий на такому проекті працює.
Є стартап (5+ років), кілька девів які супорть аби воно дальше працювало і пиляють дрібні фічі, кілька людей в сейлах, оперейшинах. СЕО знаходить інвесторів і малює супер прибутки через рік-два. Вже 5 років ні натяку на прибутковість, просто проїдання бабла інвесторів. В травні отримали ще 1кк$ інвестицій, СЕО так і каже що цього хватить ще на 2 роки і що в нього є нові ідеї як гроші закінчаться:)
Сам він їздить по burning man, поїздки в Тибет/Індію на місяць-два підряд.
Пофіг як будуть викладатись деви, і так ясно майбутнє проекту (хоч там реально ніхто більше кількох годин на день і не працює)

А що скажете ви з цього приводу? Що спричинює невдачі у IT проектах і як їх можна уникнути?

Ось щойно накопалось в тему medium.com/...​ern-dystopia-54cae7081c99
А взагалі — читайте Peopleware.

Не здужав таку велику писанину, але по темі відповім.
95% всіх проектів українське IT пише на замовлення. Як правило, всю розкрутку, аналітику і все інше замовник робить своїми силами чи силами спеціалістів тієї країни, де проект буде працювати. Отже, завдання українського айті, це написати проект і технічно його підтримувати. Ні на що інше українське айті не впливає.

Підписатись на коментарі