Якби клієнти вміли хоч думати (не те, що аналізувати) — вони не приходили би до галер щоб їх розводили як лохів.
Так ми тільки про «галери», чи про аутсорсінгові компанії взагалі?
Бо стверджувати, що геть усі аутсорсери займаються «розводом клієнтів як лохів» — це якось дуже не дуже.
Продавець — консультант: «вже провели аналіз які проблеми має вирішувати цей комп’ютер»?
Ну нащо перекручувати? Звісно, що в цій уявній ситуації продавець-консультант спитає щось накшталт «А ваш онук буде переважно грати в ігри або використовувати компʼютер для навчання?». Але — в тому і справа, що це продавець, в нього робота така.
Але в аутсорсі є різні варіанти взаємодії команди із замовником. Якщо згідно договору в команді немає ролі BA, то якось дивно очікувати, що команда відповідальна за аналіз бізнес-кейсів використання чат-ботів на сайті. Це вже скоріше питання до етапу pre-sales, на якому було б бажано зрозуміти, наскільки замовник сам в змозі адекватно формулювати бізнес-вимоги, або йому дійсно потрібна «няня» у вигляді BA / proxy product owner / you name it.
щоб клієнт просто пішов до іншої компанії.
Якщо клієнт у відповідь на цілком адекватне питання йде до іншої компанії, то це привід переглянути критерії lead qualification, бо працювати з неадекватними замовниками собі дорожче.
Єдине що — ми не знаємо, які з тим клієнтом були домовленості щодо розподілу відповідальності стосовно бізнес-аналізу. Зазвичай таке прописують у work order / project charter чи як воно називається в різних компаніях.
Останнє що тут допоможе
Аргументуєте вашу думку, будь ласка?
Єдиний кейс, який я можу уявити, коли це не допоможе — це якщо компанія на початку співпраці наобіцяла з три короба щодо володіння «доменною експертизою». Але, тут вже як в старому жарті про двох ворів: «За язика тебе ніхто не тягнув, а за базар відповіси».
Для JavaScript вже купа років як існують нормальні ліби, які всі ці задачі теж вирішують.
він очікувано скаже: ви ж спеціалісти — маєте знати як робити чат-боти.
Ну на це є чудова відповідь: «Так, звісно, ми знаємо, як з технічного боку зробити чат-бот та інтегрувати його до вебсайту. Але для цього нам треба зрозуміти бізнес-проблему, яку цей чат-бот буде вирішувати. Якщо ви бачили подібне у конкурентів, то, мабуть, вже провели аналіз, як саме чат-боти покращують користувацький досвід на конкуруючих сайтах?»
черга у воєнкомати(закреслено) ТЦК зараз ще більша ніж 24 лютого, бідні співробітники ТЦК не справляються з таким напливом добровольців, тому потрібно цілодобово приймати
Ну, взагалі-то, якщо з цієї фрази прибрати слово «добровольців», то як раз ця проблема доволі обʼєктивна, бо повістки на певну дату отримають набагато більше людей, ніж потім ТЦК здатен реально «переварити»
Але ці X та Y майже неможливо передбачити і відповідно закласти в якісь розрахунки.
Це так, заздалегідь — неможливо. Але.
Ті ж ТЦК, якщо б працювали «по уму», то могли б враховувати реальний стан здоровʼя, вмотивованість та психологічну готовність воювати, а також те, чим людина займається у цивільному житті.
А не так, як зараз — зловили на вулиці, формальна ВЛК за 15 хвилин, «придатний!», місяць учебки та під Авдєєвку.
До речі, в 2022му чув про випадки, коли люди отримували повістку, йшли до ТЦК, і якщо в них не було бойового досвіду та великої мотивації йти на фронт, а на «гражданці» вони працювали та мали стабільну роботу, їх відправляли додому зі словами «йди працюй, ти поки що в тилу корисніший»
є конкретна категорія як то «десантно-штурмові війська» то там конкретно так вже прописані вимоги з яких більшість пунктів «за здоров’я категорії обмежений» проходять як «не придатний»
зокрема по зору там 0.6/0.6 і це саме «без корекції»
Це все тільки на папері. В реальності мобілізують в ті самі штурмовики і з набагато серйознішими вадами по здоровʼю.
І, при цьому, новий законопроект взагалі скасовує термін «обмежено придатний»
что бы там не говорили, а знания, которые не используются, просто забываются. И как результат, после очень широкого диапазона вопросов, ты «входишь в двери» новой компании как прямо в НАСА, а там оказывается обычное формошлепство или ДТО-шлепство, или что-то еще такого же рода.
ИМХО вынужденная альтернатива этому — внутреннее собеседование в компании при смене проекта. Т.к. если предположить обратный случай — наняли «формошлёпа», который вполне себе справляется на текущем проекте, потом этот проект заканчивается, а на новом нужно переписывать с нуля и сразу по-правильному — вот там этот «формошлёп» с большой вероятностью жёстко зафейлится.
Т.е., другими словами, это уже довольно классическая дилемма «нанимаем в компанию или на конкретный проект»
Я з лексики, наприклад, можу зробити тільки той висновок, що Дмитро навчався в Харкові. І, так, свого часу тоді ще міліція (на що вказує слово «доаваковские», бо саме Аваков реформував міліцію в поліцію в 2014му) дійсно дуже звертала увагу на зовнішність, бо як до арабів, так і до вихідців з Кавказу в Харкові було дуже прискипливе ставлення.
Але воно ж легше робити висновки похапцем, еге ж?
А можна, будь ласка, для тих, хто не в темі — що воно таке та чим саме він придурковатий?
Можливо, тому, що сучасний Angular побудований на реактивній парадигмі, тому знання RxJS теж треба? До того ж, якщо це співбесіда на senior’а, то, зазвичай, на цьому рівні потрібне добре розуміння, як певний фреймворк працює «під капотом»?
варто поцікавитися що ці компанії робили
Ви маєте на увазі, перевірити, чи не фейкові це компанії взагалі? Ну, це може мати сенс, але я особисто не стикався з таким, щоб люди приписували собі геть неіснуючий досвід (хоч і не виключаю, що таке теж буває).
Набагато частіше компанії реальні і навіть проекти реальні, а от в описі того, що людина на тих проектах робила, і починається фантастика.
Як ви пропонуєте це перевірити, якщо ті компанії класу «галера», та, відповідно, проекти будуть під NDA — я не зовсім уявляю.
То ви просто не зтикалися з кандидатами, які дуже класно вміють в резюме та саморекламу, але потім, як виявляється, не дуже добре вміють в робити реальну роботу
В цілому, то про що ви кажете, може бути доречним для великих ентерпрайзів, але для проектів меншого масштабу зазвичай набагато простіше та дешевше використати ORM та написати зверху неї кастомну бізнес-логіку, ніж йти шляхом Hasura + зовнішній workflow рушій.
Команди які не можуть в Stateless Streaming я вже й за людей часто не сприймаю...
Втім, після такого тейку я не бачу жодного сенсу спілкуватися з вами далі.
А є вже методика no-devops?
Не те, щоб буквально no-devops, але чув про компанії, де розробники роблять суттєву частину devops роботи — принаймні, в плані опису потрібної інфраструктури в terraform / CloudFormation
якщо то pg_rest / pg_graphql в Supabase, чи prisma/hasura — потреба в розробці API може відпасти сама по собі.
Це хіба що API являє собой тупий CRUD; але зазвичай поверх доступу до даних буває якась бізнес-логіка (іноді доволі нетривіальна)
З моєї власної, але вимушено — це був стартап, в якого закінчилися гроші.
Врешті-решт, мене попросили з проекту на бенч з мотивацією: «ну тобі й так тут не подобається»
Мда... комунікація рівня «Бог»
Замість того, щоб нормально пояснити, що компанія цінує твоє бажання впровадити покращення, але нажаль от саме цей проект має певні особливості, з-за яких саме на ньому це неможливо, і далі вже пропонувати варіанти вирішення — піти з проекту якомога швидше, але на бенч, або потерпіти деякий час, поки компанія зможе зробити ротацію на інший проект — просто «попросили з проекту»
В Україні? Звісно, перепрошую пана, але тут якнайкраще підходить цитата «In God we trust, all others pay in cash».
Іншими словами — в Україні ніхто обіцянкам про equity не вірить, бо всі прекрасно розуміють, що раптом що, домогтися виконання цих обіцянок юридично майже неможливо.
Тому, погоджуватися на ті ж самі умови, як і в стабільних компаніях, але при цьому мати додаткові ризики втратити роботу або вигорання від специфіки early startup — я б сказав, треба мати дуже вагомі причини, щоб погоджуватися на таке.