Привет, Хабр! Я работаю исполнительным директором в HFLabs, а до того, как им стать, больше восьми лет занимался продажами в B2B. Моя первая сделка началась с того, что меня позвали на переговоры с вице-президентом банка. Я подумал: не с моей же рожей к вице-президентам ходить. И позвал взрослых — генерального. В день встречи утром он мне позвонил и сказал, что я уже готов к таким встречам и могу смело идти один. Было страшно.

Так вот, лето, жара, погода изматывающая. Приходит вице-президент и начинает разговор примерно так: «Вот видите во дворе Audi стоят? Я их все купил со скидкой 60%. Так что и вам придется нас услышать». Но вся штука была в том, что я уже успел по этому проекту дать скидку 30%. И это был хороший жизненный урок: скидку я дал вообще не тому человеку — он не был тем самым ЛПР. Я не разобрался в процессе и даже не спросил, кто и как будет решать по сделке. Пришлось в итоге каждый пункт коммерческого предложения объяснять, каждую строчку сметы. Например, написано у нас тестирование 2 дня. А клиент мне в ответ — зачем два, давайте один день будете тестировать!..

Дальше расскажу, какие еще истории у нас случались на переговорах и вокруг них.

https://habr.com/ru/post/701542/?utm_source=habrahabr&utm_medium=rss&utm_campaign=701542

Невозможно представить современную информационную систему (далее – ИС), которая бы стояла особняком, и не была бы интегрирована с другими. Особенно, если мы говорим о корпоративных или государственных данных. Вопросу интеграций посвящены целые книги, такие как «Шаблоны интеграции корпоративных приложений» Грегора Хопа. Некоторые издания пытаются рассматривать не только технические, но и организационные вопросы интеграции (например, «Предметно-ориентированное проектирование (DDD)» Эрика Эванса). Между тем, современный уровень технологий и высокий уровень компетентности разработчиков очень сильно снижает технические риски, выставляя на первый план организационные. В этой статье мы рассмотрим интеграции информационных систем именно с точки зрения организационных рисков.

https://habr.com/ru/post/696102/?utm_source=habrahabr&utm_medium=rss&utm_campaign=696102

Один из мифов по поводу MDM-систем — «ну что там делать-то, данные взяли, записи объединили, вот тебе и готово. А вы, мол, за работу миллионы хотите. Мы сами всё за полгода сделаем».

Чтобы объяснить, как всё обстоит на самом деле, мы в HFLabs придумали образовательный курс по клиентским данным в энтерпрайзе. Сегодня расскажу о том, как мы создавали курс, где ошибались и что меняли в процессе. Надеюсь, будет полезно небольшим компаниям, которые, несмотря ни на что, всё ещё задумываются о развитии собственных образовательных проектов.

https://habr.com/ru/post/690460/?utm_source=habrahabr&utm_medium=rss&utm_campaign=690460

Представьте ситуацию: братья-близнецы — назовём их Дима и Саша — стали клиентами одного и того же банка. У братьев совпадают отчество, фамилия, дата рождения, а ещё — адрес прописки и домашний телефон.

В 2014 году в этом самом банке мы начали внедрять MDM-систему для клиентских данных. И вместе с братьями-близнецами — а точнее с их клиентскими карточками — много всего натерпелись пережили.

Сегодня я расскажу, как одна чужая ошибка откликнулась нам спустя несколько лет и какие уроки мы вынесли из истории с очень похожими данными близнецов. А еще как допиливали продукт, исходя из весьма небанальной ситуации.

Под катом почти детективная история и много технических деталей.

https://habr.com/ru/post/673286/?utm_source=habrahabr&utm_medium=rss&utm_campaign=673286

Привет, Хабр! 10 лет назад мы запустили систему Customer Data Integration (CDI) в Yota. Речь о софте для обработки персональных данных абонентов. CDI в Yota работает совсем не так, как у других. У них это центральная система и единственная, где хранится информация об абонентах. Дальше я расскажу, как это всё устроено, на чём мы ломали копья и почему всё вышло так, а не иначе.

https://habr.com/ru/post/672430/?utm_source=habrahabr&utm_medium=rss&utm_campaign=672430

В прошлый раз я подробно рассказывал об особенностях компании-вендора. Теперь настало время поговорить о мифах и правде в работе компании-вендора. Если тема вам интересна, то давайте начнём.

Миф 1. Особые продуктовые специалисты

Один из наиболее стойких и распространенных мифов. Будто бы существует особый вид специалиста - продуктовый разработчик или продуктовый тестировщик. Очень редкий и ценный зверь. Мне кажется, что таких специальностей не бывает, но, что действительно существует, так это определенные особенности, присущие разработке продукта и как, следствие, продуктовая разработка может показаться скучной или тесной для некоторых людей.

Попробуем разобраться с качествами технического специалиста, которыми мы чаще всего оперируем для оценки в жизни:

Хороший vs Плохой

Соблазн применить эту категорию очень велик. «Хорошесть» или «плохость» не зависит от места работы, опыта работы, роста или цвета глаз. Это интегральная экспертная оценка ;-). Хорошего программиста видно по его коду, который компактен, понятен, легко поддерживается. Хорошего QA видно по въедливости, упорядоченности и понятности его кейсов. Видно его по вопросам, которые он задет до/при реализации/тестировании.

Это видно по скорости и уровню погружения в решаемую задачу и, в конце концов, по тому, к кому ходят задавать вопросы. И я не знаю, как это измерить в попугаях. Так вот, плотность хороших спецов в продуктах, аутсорсе, финтехе, abap, 1с, фронте и бэке одинаковая. И это качество точно не является специфичным для какой-то одной отрасли или направления.

https://habr.com/ru/post/663096/?utm_source=habrahabr&utm_medium=rss&utm_campaign=663096