Чому детальний аналіз конкурентів може занапастити Вашу компанію

Ні, ну звісно ж аналізуйте, звісно ж це дуже важливо. Але в цій статті йтиметься саме про нав’язливий аналіз. Наведемо приклад із реального життя про аналіз конкурентів, але це також стосується надто старанного аналізу клієнтів або технологій, наприклад. Суть у тому, що до нас звернувся клієнт, який дуже сильно цікавився конкурентами, хотів усе про них знати, хотів вивчити їх уздовж і впоперек і щиро вірив, що це важливе питання, яке приведе компанію до успіху. "А давайте проаналізуємо ще 10 конкурентів?", "А чому в усіх різні технології?" А чому в них Java?", "А може нам на Node розробити?", "А чому prom.ua на Python?", "Може на CMS зробимо? Або конструкторі?". І сотня різних інших запитань. І це нормально, будь-який директор або власник має право переживати за те, щоб не бути гіршим за конкурентів. Однак на цей момент ми вже зібрали багато інформації про конкурентів, але зовсім не просунулися в іншому критично важливому аналізі...

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

"Добре, завтра з 11 зможемо все детально подивитися, але я б запропонував цей час витратити на цінніший аналіз, тому що знайти якісь деталі про конкурентів ми зможемо, але це Вам ні про що не скаже. Так само як якщо дивитися на місто й аналізувати - 'чому тут такі дороги, чому під таким кутом, чому ця будівля стоїть там, а не на 100 метрів далі, чому міст у такому дивному місці, адже це нелогічно'. Місто 500 років тому було маленьким селом на торговому шляху. Де частіше проїжджали каравани - там сформувалися протоптані дороги, а потім проклали кам’яну кладку, а потім залили асфальтом. Мости поставили там, де в той момент було доречно згідно з технологіями дерев’яних мостів їх прокласти. А потім це вже в комплексі зв’язалося з дорогою, біля дороги люди побудували будинки, а потім уже ніхто не міг знести будинки, щоб змінити архітектуру доріг і мостів, тому що за кожен район відповідали різні начальники.

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

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

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

Рішення за Вами, але я б запропонував витратити завтрашній час саме на аналіз, який приведе до збільшення прибутковості компанії і в майбутньому створював би інновації для компанії замість ходіння по граблях конкурентів, повну історію яких ми не знаємо і ніхто її не розповість."

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

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

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

Не порівнюйте себе з тими, хто вже 20 років пише свої програмні рішення. Це зовсім інший світ. Продукт, якому рік, і продукт, якому 20 років - це як село і місто. Звісно, кожен хоче одразу стати великим. Але це неможливо, закони фізики не дозволяють таких квантових стрибків. Та й узагалі задумайтеся, чи хочете Ви ставати великою, бюрократичною, закріпаченою, повільною і консервативною компанією. Або Вам подобається бути маленькими, гнучкими, пробувати нові технології, швидко адаптуватися під навколишній світ. У великих компаній свої головні болі, не поспішайте їх приймати. Ми в компанії https://ingello.com завжди прагнемо балансу, і в плані розміру здорово бути і великими, і малими. Тому наші команди програмістів децентралізовані, у нас немає єдиного командного центру, але є єдині технологічні бази, що зберігають досвід, здатні його доопрацьовувати й ділитися напрацюваннями, але без єдиної гетерогенної ентерпрайз-оболонки.

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

Успішних Вам проєктів, колеги!