Конференция

В этом году в секции Team на DUMP выступит agile-коуч компании Wiley Илья Якямсев. Мы поговорили с Ильей о его докладе, злом стендапе и о том, как сценический опыт помогает вести тренинги.

Илья, привет! На DUMP ты выступишь с докладом Говорите, пожалуйста! Как построить эффективную коммуникацию в команде. А еще ты выступаешь как стендап-комик. Мы не будем тебя просить шутить в нашем интервью, а будем просто задавать вопросы тебе-менеджеру, и тебе-комику.

• Расскажи подробнее, о чем будет твой доклад? Можно немного спойлеров:)

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

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

Как инструмент будем использовать мессенджер, идеи будут вокруг эджайл практик. Прозрачность, инспекция, адаптация - примерно в этом поле.

• Ты постоянно работаешь с людьми, выстраиваешь и оттачиваешь процессы в командах... Много ресурсов отнимает у тебя самого постоянная коммуникация?

Коммуникация занимает у меня всё рабочее время, потому что я разучился программировать, а делать программные продукты мне нравится. Как приличный человек, я стараюсь уменьшить количество и повысить качество, в быту это называется эффективность. Из ресурсов часовое совещание с хорошими людьми стоит примерно один апельсин, часовое совещание с хорошими людьми в гневе стоит примерно кусок мяса.

• Где ты учился взаимодействию в команде (или с этим рождаются?) и как прокачивал этот полезный скилл?

Я всегда старался брать обратную связь от всех людей с кем работал и старался хоть маленько изменять на практике своё поведение. И ещё я много читаю и смотрю видео как работают другие люди.

Да, важно - мне это нравится.

• Как на работу твоей команды повлияла пандемия? Что изменилось?

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

Частично и об этом буду говорить в своём докладе.

• С чего начиналась твоя карьера agile-коуча? Что считаешь твоим (командным) успехом, а что - провалом?

Моя карьера agile-коуча началась с того, что наш предыдущий коуч ушёл в другую компанию, а меня пригласили на его место из производства. Успехи у меня здесь не самые большие, меньше, чем в любом производстве, потому что производством я занимаюсь около двадцати лет, а коуч вот прям коуч всего полгода. Поэтому и успехи и провалы у меня пока непонятные, особо не с чем сравнивать.

Труднее всего не давать советы и не пытаться прямым действием исправить систему. К этому пытаюсь привыкнуть.

• Как ты пришел к своему увлечению стендапом? Какой момент стал поворотным?

Мне понравился Камеди Клаб, потом я начал писать тексты в Самарский Камеди Клаб, потом начал выступать сперва с монологами Десять шуток на одну тему. После года занятий я открыл в сети стендап, меня немедленно выгнали со сцены с формулировкой никогда больше здесь не будет ни тебя, ни вот этой вот отвратительной вещи. Потом года через три мы в городе всё-таки додумались делать открытые микрофоны, и вот с 2013 года я регулярно выступаю.

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

• Какие комики тебя вдохновляют? А проекты и команды?

Меня вдохновляют комики с идеями, где кроме шуток есть интересные точки зрения и/или не банальная литература. Даг Стенхоуп, Джордж Карлин, Саймон Амстел, Эдди Изард, Стюарт Ли.

Из проектов и команд меня вдохновляет текущее место работы, в Wiley есть куча проектов в разных фазах становления производства и глубины проработки, а область деятельности - высшее образование и наука - очень необычна для IT в России, я каждый день узнаю что-то новое.

• Где ты берешь материал для шуток? Как его отрабатываешь и проверяешь? Кто герои твоих выступлений?

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

• Что ты чувствуешь, когда стоишь на сцене, слышишь смех в зале? А когда выступаешь на конференциях? А прорывается наружу стендапер?

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

Чувствую удовольствие. Иначе бы не занимался.

• Шутишь ли ты про работу со сцены? И наоборот - привносишь ли опыт комика в работу?

У нас с Wiley есть договорённость, что я не рассказываю про работу, я её соблюдаю, и считаю эту договорённость вполне нормальной. Про работу у меня есть конференции и весь этот коучинг, работа насыщенная, по окончании рабочего дня я вообще не хочу говорить о работе. Всё сходится.

Опыт комика в работу привношу, так как часть комедии это умение привлечь внимание, понимать ритм разговора, замолчать когда надо, выдерживать паузу. К тому же комедия очень сильно развила мой логический аппарат - писать шутки это разрушать и снова собирать логические конструкции.

Ну и тренинги мне из-за этого опыта вести легко и приятно.

• Есть вероятность, что тебе надоест карьера в Wiley и ты будешь собирать залы?

Пока не надоедает, есть постоянный вызов, и я вижу результаты своих действий. Буду собирать залы - там посмотрим. Пока я собираю небольшие, скромные помещения.

• Представь, что ты вернулся на 10 лет назад в прошлое, что посоветуешь себе?

Не метаться, идти в одну сторону, и если пошёл, то не пытаться в трудные минуты вернуться обратно. Но вряд ли это получилось бы у меня десятилетней давности, это наживное.

Да, ещё хороший совет - не бросать основную работу пока не нашёл другую основную работу.

• А кем видишь себя еще через 10 лет?

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

Мне очень нравится удалёнка.

• На DUMPе ты мы увидим твой полезный доклад для менеджеров разработки. А где можно посмотреть твой стендап (вживую - мы все очень соскучились по офлайну)?

У меня будет концерт в Екатеринбурге, его организуют местные ребята в лофте Место. Вечер 14 мая в 22:00 (после конференции). Приходите, если что.

А послушать Илью как спикера секции Team можно 14 мая в конгресс-центре ЭКСПО оффлайн или в нашей онлайн-трансляции. Билеты выбирай здесь!

Увидимся на DUMP!

В этом году в секции Team на DUMP выступит agile-коуч компании Wiley Илья Якямсев. Мы поговорили с Ильей о его докладе, злом стендапе и о том, как сценический опыт помогает вести тренинги.

Илья, привет! На DUMP ты выступишь с докладом Говорите, пожалуйста! Как построить эффективную коммуникацию в команде. А еще ты выступаешь как стендап-комик. Мы не будем тебя просить шутить в нашем интервью, а будем просто задавать вопросы тебе-менеджеру, и тебе-комику.

• Расскажи подробнее, о чем будет твой доклад? Можно немного спойлеров:)

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

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

Как инструмент будем использовать мессенджер, идеи будут вокруг эджайл практик. Прозрачность, инспекция, адаптация - примерно в этом поле.

• Ты постоянно работаешь с людьми, выстраиваешь и оттачиваешь процессы в командах... Много ресурсов отнимает у тебя самого постоянная коммуникация?

Коммуникация занимает у меня всё рабочее время, потому что я разучился программировать, а делать программные продукты мне нравится. Как приличный человек, я стараюсь уменьшить количество и повысить качество, в быту это называется эффективность. Из ресурсов часовое совещание с хорошими людьми стоит примерно один апельсин, часовое совещание с хорошими людьми в гневе стоит примерно кусок мяса.

• Где ты учился взаимодействию в команде (или с этим рождаются?) и как прокачивал этот полезный скилл?

Я всегда старался брать обратную связь от всех людей с кем работал и старался хоть маленько изменять на практике своё поведение. И ещё я много читаю и смотрю видео как работают другие люди. Да, важно - мне это нравится.

• Как на работу твоей команды повлияла пандемия? Что изменилось?

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

Частично и об этом буду говорить в своём докладе.

• С чего начиналась твоя карьера agile-коуча? Что считаешь твоим (командным) успехом, а что - провалом?

Моя карьера agile-коуча началась с того, что наш предыдущий коуч ушёл в другую компанию, а меня пригласили на его место из производства. Успехи у меня здесь не самые большие, меньше, чем в любом производстве, потому что производством я занимаюсь около двадцати лет, а коуч вот прям коуч всего полгода. Поэтому и успехи и провалы у меня пока непонятные, особо не с чем сравнивать.

Труднее всего не давать советы и не пытаться прямым действием исправить систему. К этому пытаюсь привыкнуть.

• Как ты пришел к своему увлечению стендапом? Какой момент стал поворотным?

Мне понравился Камеди Клаб, потом я начал писать тексты в Самарский Камеди Клаб, потом начал выступать сперва с монологами Десять шуток на одну тему. После года занятий я открыл в сети стендап, меня немедленно выгнали со сцены с формулировкой никогда больше здесь не будет ни тебя, ни вот этой вот отвратительной вещи. Потом года через три мы в городе всё-таки додумались делать открытые микрофоны, и вот с 2013 года я регулярно выступаю.

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

• Какие комики тебя вдохновляют? А проекты и команды?

Меня вдохновляют комики с идеями, где кроме шуток есть интересные точки зрения и/или не банальная литература. Даг Стенхоуп, Джордж Карлин, Саймон Амстел, Эдди Изард, Стюарт Ли.

Из проектов и команд меня вдохновляет текущее место работы, в Wiley есть куча проектов в разных фазах становления производства и глубины проработки, а область деятельности - высшее образование и наука - очень необычна для IT в России, я каждый день узнаю что-то новое.

• Где ты берешь материал для шуток? Как его отрабатываешь и проверяешь? Кто герои твоих выступлений?

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

• Что ты чувствуешь, когда стоишь на сцене, слышишь смех в зале? А когда выступаешь на конференциях? А прорывается наружу стендапер?

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

• Шутишь ли ты про работу со сцены? И наоборот - привносишь ли опыт комика в работу?

У нас с Wiley есть договорённость, что я не рассказываю про работу, я её соблюдаю, и считаю эту договорённость вполне нормальной. Про работу у меня есть конференции и весь этот коучинг, работа насыщенная, по окончании рабочего дня я вообще не хочу говорить о работе. Всё сходится.

Опыт комика в работу привношу, так как часть комедии это умение привлечь внимание, понимать ритм разговора, замолчать когда надо, выдерживать паузу. К тому же комедия очень сильно развила мой логический аппарат - писать шутки это разрушать и снова собирать логические конструкции.Ну и тренинги мне из-за этого опыта вести легко и приятно.

• Есть вероятность, что тебе надоест карьера в Wiley и ты будешь собирать залы?

Пока не надоедает, есть постоянный вызов, и я вижу результаты своих действий. Буду собирать залы - там посмотрим. Пока я собираю небольшие, скромные помещения.

• Представь, что ты вернулся на 10 лет назад в прошлое, что посоветуешь себе?

Не метаться, идти в одну сторону, и если пошёл, то не пытаться в трудные минуты вернуться обратно. Но вряд ли это получилось бы у меня десятилетней давности, это наживное.

Да, ещё хороший совет - не бросать основную работу пока не нашёл другую основную работу.

• А кем видишь себя еще через 10 лет?

Я рассчитываю настолько хорошо овладеть эджайлом и практиками коучинга, а также инструментами для распределённых команд, чтобы заниматься этим из Самары, временами наезжая в иные города с хорошими идеями, тренингами, лекциями, мастер-классами. И со стендапом. Мне очень нравится удалёнка.

Послушать Илью как спикера секции Team можно 14 мая в конгресс-центре ЭКСПО оффлайн или в нашей онлайн-трансляции. Подробнее о программе.

Когда играешь в особенно крутую игру, останавливаться не хочется, пока не пройдешь всё до конца. А ещё хочется создать свою игру! Знакомая история? Для участников DUMP тоже:) В этом году впервые на конференции будет представлена секция GameDev.

Мы решили узнать больше о разработке игр и пообщались с представителями индустрии из компании Targem Games Евгением Бушуевым (Game Designer Crossout) и Алексеем Честных (Creative Director).

Расскажите, как вы попали в игровую индустрию?

Женя: Я заканчивал УПИ, Менеджмент в энергетике и на промпредприятиях. 15 лет назад высшее образование было некой защитой от армии. Дальше я мог пойти по специальности, но этот вариант казался тоскливым. И как-то раз я увидел на ag.ru новость о том что в Екатеринбурге есть студия Targem. Хотел устроиться здесь менеджером, но после интервью меня взяли геймдизайнером. Это было супер предложение! Диплом менеджера я получил уже позже, через год. Но на момент собеседования переживал, что заветной корочки не было.

Алексей: Начну издалека. Я с детства был повернут на видеоиграх. Просто был маньяком, зависал при виде любой анимированной гифки. Кажется, пугал этим родителей. Помню, ездили в Москву, и там в Парке Горького был вагончик с игровыми автоматами, 16-битными. Тогда я попал в рай. Изучал, как что работает. Пиксельное безумие! У меня был компьютер Spectrum. Я пытался делать на нем пиксель арты.

Всегда, когда была возможность во что-то поиграть, я ее использовал.

Как я сюда попал? Ну, наверное, не то чтобы случайность. Я получил высшее образование, филологическое, и собственно, до этого никогда не работал, жил в своем мире эльфов. Через полтора года после выпуска нашел объявление о том, что Targem Games набирали сотрудников.

Какая игра, на ваш взгляд, является иконой геймдизайна?

Женя:

Они сменяются, их же много на самом деле. Какой-то одной совсем нет. Я X-COM любил классический очень часто к нему возвращался. Очень важная для меня игра.

Когда я поработал в геймдеве несколько лет, я начал думать, как сделать любимые игры еще лучше. В X-COM был тип прокачки, где нужно таскать тяжелые пушки, чтобы качать силу, бегать по карте ради скорости. В результате, чтобы играть эффективно, нужно было играть странно. Или например в Тарелку не зайдешь, чтобы заряд плазмы не получить. Пули можно на базе забыть, а во второй части вовсе с подводным оружием на надводную миссию улететь.

Еще хочется выбрать альтернативную икону. Есть Герои, но я больше предпочитал Disciples. Она проще, цифры там меньше и мне нравилось, что там больше контроля над происходящим. При этом она и выглядит классно.

Алексей:

Я соглашусь с Женей. Это, конечно же, X-COM, причем второй. Я до сих пор помню звуки стрельбы пушек и гибели инсектоидов. Цикличность мне очень нравилась и это вылилось в то, что я до сих пор люблю игры с петлями в геймплее. По началу из икон были X-COM, Герои Меча и Магии вторые и третьи.

Еще в детстве я открыл для себя эмуляторы, а в особенности, игру Chrono Trigger. Она перевернула мой мир. Я помню, что сидел и играл в неё двое суток без остановки!

Вот две игры, которые являются для меня иконами Chrono Trigger и (внезапно) Front Mission 3. Это лучшая игра про роботов, в принципе. Очень дорогая, с прекрасными роликами и сюжетом.

Но иконы меняются. Поэтому недавно я был поражен игрой Undertale. Финальный босс меня очень порадовал. Игра вся пиксельная, трехцветная, а босс сделан в Фотошопе из различных фотографий. Но это лишь половина прикола. Вторая часть заключается в том, что босс выкидывает тебя из игры, если ты умираешь. Это меня поразило и порадовало. В NieR: Automata тоже очень любопытные механики, которые ломают четвертую стену. В принципе, из последнего, именно эти две игры выбивают из привычного гейминга.

А какая топовая игрушка была топовой для Spectrum?

Алексей:

Конечно же, Элита. Тогда производили впечатление такие игры как Саботаж. Там, где был крупный персонаж, во весь рост это производило впечатление. Еще там был первый Wolfenstein вид сверху. The Verse тоже была классная та в которой робота строишь.

Какую роль геймдизайн играет в разработке игр? В чем ежедневный труд и какие бывают типы?

Женя:

Проще всего сравнить с режиссером. По крайней мере, главного дизайнера на проекте. Геймдизайнер такой волшебный человек. С одной стороны, он полностью представляет себе игру: зачем и кто в это будет играть, все правила. От него идет задание программистами, художникам. Их результат дизайнер пытается слепить воедино в то, что он изначально себе представлял. На самом высоком уровне делает концепт, а на самом низком работает руками.

Алексей:

Классифицировать дизайнеров можно по-разному. Выделяют нарративных дизайнеров, которые отвечают за текст и повествование. Левел дизайнеры делают уровни для игры. Дизайнеры игровой логики решают, где нужно стрелять и так далее.

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

А откуда появляются геймдизайнеры?

Женя:

Как по мне, идеальный путь это геймджемы. Соревнования, где людям дают тему и срок, чтобы сделать игру. По сути, это вариация хакатона. Лучший способ попасть в геймдизайнеры сделать игру. Благодаря дедлайну, такой формат позволяет не оттягивать выпуск игры мечты навечно, а создать достойный MVP за короткий срок. Также ты сможешь попробовать каждый аспект создания игры, что потом облегчит коммуникацию с коллегами по команде.

Второй путь это много играть. Просто разбирать игры и понимать как они сделаны, почему они так сделаны. Третий пользоваться чужими разборами на YouTube. Это кажется идеальным форматом в наше время.

Алексей:

Геймдизайнер товар штучный и редкий. Как бы ни художник, ни программист. Нужен толковый человек, который играет в игры. В последние годы ситуация улучшилась благодаря тому, что появились курсы и бесплатные движки. Сейчас самое удобное время для разработки Unity и Unreal копеечные. Самые удобные инструменты.

Поэтому сейчас у нас более строгие требования, и кандидаты приходят подготовленными. Сейчас мы ждём, что кандидат сделал хотя бы один свой прототип. Может, даже сделал какую-то игру и продал ее на AppStore. Мы ожидаем людей с опытом либо прототипов, либо джемов, либо пройденных курсов. Плюс, какие-то элементарные теоретические знания. Например: понять что такое кривая сложности, игровой баланс, метаигра. Немножко терминов, но главное опыт. Мы стараемся брать молодых людей, плотно с ними работать, проводить для них ивенты и лекции.

Возраст у геймдизайнера имеет значение?

Алексей:

Мне кажется, что всё равно какая-то пассионарность больше есть у молодежи. Вот последние успешные дизайнеры, которых мы наняли, они студенты последних курсов, у них горят глаза. Потому что знания знаниями, но важен драйв. Главное свойство геймдизайнера это не только обладать видением, но уметь его доносить до других. Заражать других не мечом, а словом. Поэтому, лично я, по поводу найма отдаю предпочтение джунам. Потом мы воспитываем их в компании на более высокие грейды и зарплаты.

Как последний год изменил индустрию?

Алексей:

Индустрия только выросла, предыдущий год был очень прибыльным. Люди стали больше играть. На подъеме мобильный гейминг. Про тренды геймдизайна: сейчас время ремейков. Это происходило в обычной масс-культуре, но в играх тоже произошло, хоть и с опозданием.

В Targem изменилось то, что мы ушли на удаленку, как и многие. В офисе могли находится только новички, которые проходили свой первый срок, и их наставники. У нас были большие перемены в организации труда. Это пошло нам на пользу.

Какие практики помогают сохранить эффективность?

Алексей:

Мы стали больше фиксировать информацию и чаще созваниваться. Отмечаем затраченное на задачи время в трекере. Я не в большом восторге, признаюсь честно. Жду, когда мы снова будем работать как прежде.

Некоторые игры достаточно долго делают. Как угадать с тем, что будет релевантно и актуально через несколько лет?

Алексей:

Я боюсь, что правильный ответ ты можешь не угадать. Нет инструментов, чтобы заглянуть в будущее. Нужно принимать риски и делать соответствующие решения. Индустрия игр это heat-driven индустрия, как кино. Выходит 1 000 игр из которых, одна игра получает всё, 9 в топе получают половину, а остальные ничего. К сожалению, так это работает. Есть пул игр, из которых что-то может выстрелить. Нет никаких гарантий.

Мы, Targem, старались следовать за трендами, но ничего не получалось. Тренды нужно создавать. Мы начали создавать казуалки, когда они были на подъеме, а закончили, когда уже весь интерес к ним утих. Надо рисковать, делать что-то смелое. И делать то, к чему душа лежит. Ради денег ничего не выйдет.

Женя:

Ты должен ощущать вакуум, пустое место, которое собираешься занять. Например, в этом месте должна стоять игра, ее не хватает. Плюс, свои сильные стороны использовать. Трендам следовать ты всегда опоздаешь, высокая конкуренция.

Где баланс между чистым творчеством и коммерческим проектом, зарабатыванием денег?

Алексей:

Мы стараемся в наши текущие проекты вкладывать душу. Коммерческий проект - это не синоним плохого проекта. Мы стараемся создавать ценности. При этом Targem - это бизнес, а цель бизнеса - заработать. Поэтому мы больше про коммерческую разработку. Если мы говорим о чистом искусстве, то выступаем в роли ремесленников.

Есть в Targem практика свободных дней? В которые кто-то пилит свои проекты или занимается творчеством?

Алексей:

У нас пару лет проводится неделя свободного творчества. Где люди могут свои старые таски пособирать, что-то еще поделать. И в рамках таких недель некоторые фичи могли быть добавлены в игру. Это не очень системно. Мы пока в другой психологии все напряженные, нужно выполнять план, делать новые фичи. Наверное, мы потихонечку будем внедрять эту тему. Хочется больше делать для того, чтобы атмосфера была творческая.

Кто из гейм-дизайнеров ваш топ?

Женя:

Я скорее назову студии, а не людей. Потому что я точно не знаю, кто у них занимается дизайном. Мне очень нравится студия Klei, они выпускают разные игры. Они продуманные, красивые, расширяют пространство этого жанра. Как пример, назову Invisible, Inc.. Я больше всего с ней времени провел. Последнее у них Griftlands, Ninja Mark, Dont Starve, Dont Starve Together.

Кодзиму я не то чтобы люблю, но отношусь к нему с большим уважением.

Самое большое впечатление за последнее время произвел Disco Elysium, это студия ZA/UM. Они при этом из нашей культуры. На одном из награждений благодарили Маяковского и Цоя. Это очень круто.

Алексей:

Мой любимый дизайнер Тим Шейфер. Мне нравится то, что он сам делает визуальный арт и дизайн игр. Мне нравятся инди-игры. Например, создатель Undertale. Создатели Hades Supergiant Games. Они тоже иногда раздвигают жанры.

Создатели FTL Subset Games; они создали целое поколение последователей.

Какой был самый громкий фейл?

Женя:

Я самоед, поэтому всё, что выпускалось, было для меня не совсем так и не совсем то. Наверное, это синдром самозванца. Я всеми проектами над которыми работал несколько недоволен, но так чтобы совсем фейл такого не назову.

Алексей:

Я соглашусь с Женей, мы с ним в этом плане похожи. Всегда есть общее недовольство, всегда можно было сделать лучше. Но для меня проект Sledgehammer фейл. Я был там и сценарист, и дизайнер, и менеджер. Мы долго пытались его согласовать, я писал десятки концептов, но ничего не подходило. А когда думал, что уйду, предложил концепт игры и его приняли. Я был недоволен и роликами, и сюжетом. А потом я в него как-то поиграл много лет спустя и удивился там столько геймплея, оружия, она такая большая. И, в принципе, не так всё плохо. Поэтому в моменте есть недовольство тем, что делаешь.

Чем больше всего гордишься?

Алексей:

Ex Machina. Я считаю её своим полностью проектом. У меня есть ощущение, что она получилась именно такой, в основном, из-за сценария. И, наверное, Crossout. Это черный лебедь. Никто не знает, почему оно работает. Что-то получилось, непонятно благодаря и вопреки. Но этот проект прямо хороший.

Еще у нас была ключевая игра, с которой мы вышли на консоли Armageddon Riders. Это был Sledgehammer, который сам по себе противоречивая игра. На его движке за полгода мы сделали Riders. На PC игра прошла мимо, а вот на консолях вышла хорошо и мы смогли заработать.

Star Conflict первый наш онлайновый проект, смелый эксперимент. Было интересно, получится ли что-нибудь? Но он до сих пор живет, несмотря на то, что похожие игры с драйвом приходили и уходили. Мы любим все наши проекты во все вложена душа.

Спасибо ребятам за такую подробную беседу! Надеемся, тебе было интересно. А сейчас немного деталей конференции и секции GameDev:

14 мая в секции GameDev выступят 7 спикеров. Их можно услышать офлайн и онлайн, задать вопросы. Подробнее о программе https://dump-ekb.ru/gamedev

А в бесплатном стриме с конференции в рамках секции выступит Марина Бондаренко. Ее доклад Гиперказуальные игры. Обзор сделок и рынка смотри по ссылке в нашем телеграм-канале https://t.me/DUMPOnline. Ссылку на трансляцию опубликуем там 14 мая.

Одно дело почитать теорию об уязвимостях и совсем другое увидеть последствия и защититься на практике. Специалист по защите приложений в DINS Иван Юшкевич предлагает испробовать это во время конференции PHP Russia 2021, где он представит свой практический доклад Веб-безопасность для начинающих.

А в качестве небольшого тизера к выступлению Иван рассказал нам о том, зачем вообще программистам нужно разбираться в вопросах безопасности. Прочитав статью, вы узнаете, как начать свой путь к Application Security, какой профит это принесет и как часто стоит проводить аудит в компаниях разной величины.

Расскажи о себе и своей работе, чем ты занимаешься?

Я специалист по защите приложений. Занимаюсь ApplicationSecurity в компании DINS. В этой области я уже лет десять. Начинал как специалист по защите информации, потом занимался тестированием на проникновением.

Что планируется на конференции и почему именно такая тема доклада?

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

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

На конференции я расскажу, почему prepared statements только усложняют код, а возможность внедрения JavaScript-кода на сайте не является багом. Кроме того, на практике мы с участниками попробуем накрутить лайков в социальных сетях, украдем криптовалюту и получим доступ к самым большим секретам пользователей. А потом я объясню, что нужно делать, чтобы не допустить подобных случаев в веб-приложении.

Как ты думаешь, кому будет полезен твой доклад?

1. Узнает ли, например, сеньор что-то новое, если он пойдет на этот доклад? Нет.

2. Узнает ли что-то миддл? Вполне. Возможности, ничего нового в инструментах он и не узнает, но может задуматься над некоторыми аспектами безопасности.

3. Узнает ли что-то джун, который пойдет на доклад? Абсолютно точно.

Почему так? Потому что есть более интересные доклады для сеньоров. Что-то небанальное, о том, как построить самолет из желудей и спичечных коробочек. А для миддла написание кода одна из актуальных задач.

Программисту действительно нужна практика в вопросах безопасности? Если да, то зачем?

Да. Если говорить возвышенными словами это нужно, чтобы допускать меньше ошибок в коде. А если спуститься к материальному языку, то проблема безопасности обходится для компании в определенное количество денег. Поэтому любая ошибка, которую изначально не допустили или обнаружили на этапе создания, обходится компании дешевле, чем ее исправление потом.

В чем профит для разработчика? Ведь у компании куча денег, зачем ему их считать? Он может расширить свои компетенции и в некоторых случаях претендовать на звание Security Champion в компании.

Что нужно сделать, чтобы стать специалистом в твоей области? Пройти обучение и стать сертифицированным специалистом, или есть другой путь?

Мне кажется, в первую очередь должно быть желание: вам должно быть интересно этим заниматься. Большую часть информации о безопасности приложений сегодня можно почерпнуть из интернета. Есть куча ресурсов, где можно прокачать свои навыки. Заниматься вопросами безопасности можно и без трудоустройства в компании. Можно участвовать в bug bounty и получать за это хорошие деньги.

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

А есть люди, у которых список сертификатов на целую страницу А4, они их просто собирают, для галочки. Любая компания может сказать, что она выдает сертификат, другой вопрос, что действительно стоит за этим сертификатом. Если есть желание, от любых курсов и от любого сертификата можно получить намного больше преимуществ, чем если вы просто ждете, что в какой-то момент станете профессионалом.

Как можно убедить бизнес уделить время вопросам безопасности? Какие ты слова подбираешь для того, чтобы этого добиться?

Слова очень простые. Причем, не мои, эту мысль озвучили уже до меня: исправление уязвимости на этапе разработки стоит около ста долларов, а исправление уязвимости в выпущенном продукте на порядки дороже. Вот и все.

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

Надо понимать, что мы пишем код безопасно, скажем, месяц. Можем написать тот же самый код за неделю, не особенно запариваясь. Если оценить время разработчика, на безопасное написание тратятся лишние деньги. Но из-за этого заблуждения, желания сэкономить и написать побыстрее, ружье может выстрелить, и эта экономия не окупится.

Можно провести такую параллель: радость от сэкономленных денег намного короче, чем слезы от плохой татуировки. Сэкономили денег, сделали татуировку, радуемся два дня, а потом думаем: там же какой-то черт нарисован, а я тигра хотел! И от этого уже никуда не деться.

Достаточно ли сделать один раз аудит, или нужно выстраивать процесс внутри компании?

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

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

Считаешь ли ты свой доклад нетривиальным?

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

PHP Russia 2021 пройдет 28 июня вМосква, Radisson Slavyanskaya. Но уже сегодня можно ознакомиться с расписанием и присмотреть доклады, которые вы точно не захотите пропустить.

А еще вы можете выбрать формат участия: онлайн или оффлайн. Не забудьте купить билеты заранее: стоимость конференции постоянно растет чем ближе к мероприятию, тем дороже.

За несколько лет DevOps из экзотики превратился в набор практик и технологий, который помогает эффективно решать прикладные задачи и приносит компаниям осязаемую пользу.

В этом году на конференции мы решили сфокусироваться на реальных кейсах, которые не первый год с помощью DevOps развивают продукты и сервисы. Спикеры DUMP готовы поделиться своими примерами, подходами и метриками. От магии, какой казался DevOps некоторое время назад, перейдем к реальным инструментам. В этом нам помогут спикеры:

• Виктор Еремченко (Miro). Он расскажет про Cloud native vs self-hosted solutions при масштабировании инфраструктуры. Что выбрать? Опыт Miro

• Александр Тарасов (ANNA Money) и его доклад Не Helm'ом единым

• Кирилл Казарин (DINS) с темой 4 золотых сигнала на службе SRE инженера

• Виталий Хабаров (Экспресс 42) готовит доклад Как измерить DevOps?

• Руслан Тагиров, Чесноков Никита, Бендин Максим (Ростелеком ИТ) и Платформа Цифровых Продуктов Ростелекома. Как развивать DevOps-инфраструктуру в "матером энтерпрайзе"

• Димитрий Сугробов (Леруа Мерлен) выступит с докладом Dev.+Ops или строим идеальный процесс поставки

• Артём Картасов (Postgres.ai) и тема Без отката до рассвета: автоматическая проверка PostgreSQL миграций в CI

• Владимир Лила (Контур) и его доклад Пишем надежные ansible роли. Этот доклад будет в открытом доступе - он включен в программу бесплатного стрима с конференции. Как 14 мая послушать Владимира и других спикеров, рассказали здесь.

Кстати, на прошлой конференции Владимир Лила и его доклад Эластик весом с петабайт вызвал большой интерес и отличные отзывы:

• Еще один спикер секции DevOps - Дмитрий Харламов (Provectus) и его Долгий путь от bash до gitops. Об этом мы поговорили подробнее. Вот, что Дмитрий рассказал о своих проектах и докладе:

У нас в Provectus множество различных проектов: от типовых, до очень необычных. Зачастую запуск проекта, а тем более стартапа, без знаний бизнеса или без понимания конечной инфраструктуры (а если еще и ТЗ меняют на ходу) - боль. Боль, как для Ops команды, так и для Dev. Необходимо быстро реагировать на ситуацию, иметь возможность расширить\сократить\заменить людей на проекте или стек целиком. Но что бы ни случилось, требуется сделать хорошо и соответствовать определённым стандартам.

Ещё один важный фактор оставить после запуска проекта знания, передать артефакты, чтобы у заказчика была возможность обслуживать инфраструктуру своими силами. Или иметь возможно повторить проект с небольшими изменениями, часто в сжатые сроки.

Взяв за основу наработки одного из наших DevOps инженеров (это был многим знакомый Terraform), мы создали инструмент, который позволял развернуть базовую инфраструктуру в AWS с упором в EKS, и что немаловажно, удалить все созданное без остатка. Мы решили назвать проект Swiss-Army-Kube.

Расскажи нам подробнее, о чем будет твой доклад? Почему ты выбрал именно эту тему?

Я расскажу о пути, который мы преодолели, разрабатывая наш инструмент. О том, что мотивировало, а что мешало в процессе. Для меня это новый опыт по продвижению проекта, который не приносит денег, но я надеюсь, что будет полезен. Я долгое время сам пользовался инструментами, которые кто-то разрабатывал, и теперь пришло время восполнить карму и двигаться дальше. Возможно, кто-то узнает в этой истории себя и поймет, что ему не хватает. Спойлер: точно не этого! Думаю, доклад будет полезен и некоторые не допустят наших ошибок. Большой наградой для меня будет, если участники запомнят что-то из моего выступления.

Что подтолкнуло к созданию Swiss-Army-Kube и почему вы решили сделать проект открытым?

Задумка создать такой проект была в компании давно. У нас большой опыт и много инженеров (а это та самая база, на которой хочется построить подобный инструмент). Мы сделали его открытым, потому что это часть маркетинговой стратегии. Мне же близка идея, что знаниями нужно делиться, улучшать свои проекты и помогать другим. Такой айти-коммунизм во всей красе.

Чем занимается Provectus? Расскажи о самых необычных проектах и своей работе в компании

Основное направление - это консалтинг в сфере ML/AI. Мы помогаем запускать стартапы, разрабатываем ПО под заказчиков.Из необычных проектов могу назвать Hydrosphere.io. Это дивный мир machine learning. До встречи с ними я слышал, что есть математики, они тренируют модели, гадают на цифрах...И в общем, я был прав.

Как на работу команды повлияла пандемия?

Тут все очень индивидуально. Кто-то стал больше работать удаленно, кто-то не поменял свой привычный график. Были непростые моменты, когда поговаривали об отпусках за свой счет. Но Provectus всегда открыто заявляет, что ее самый важный актив - это команда профессионалов. Поэтому компания делает все возможное, чтобы сохранить команду. Это классно!

Какие тренды в DevOps появились за последний год?

Чаще стал слышать про ML, есть общий тренд перехода на сервис, чтобы как можно меньше заниматься низкоуровневыми задачами. Отчасти это хорошо. Ты можешь сконцентрироваться на своих задачах. Но где нам потом, лет через 10, брать людей, которые знают, как все это работает - большой вопрос.

Что бы ты сказал компаниям, которые не понимают необходимость применения практики DevOps?

А такие еще есть?:) Рынок диктует жесткие правила и практики DevOps нацелены на непрерывность процесса, гарантию чистоты кода. Да, это не серебряная пуля и зачастую компаниям приходится ломать устоявшиеся процессы, привыкать к новому - это может усложнять работу. Но стоит понимать, что гиганты рынка Netflix, Amazon, Google уже давно применяют эти практики и в целом довольны. Тем, кто не готов взять процесс трансформации в свои руки, рекомендую обратиться к компаниям, которые на этом специализируются. Как говорится, не попробуешь - не узнаешь.

Работа с бизнес-задачами учит быстро реагировать на изменения рынка, подстраиваться под заказчика, строить работу в команде. Какие хард скилы необходимы DevOps-инженеру и какие софт скилы приобретаешь со временем?

Стоит понимать специфику нашего и зарубежного рынка. У нас нет базы подготовки и адекватного понимания, чем должен заниматься DevOps-инженер. Из хард скилов могу назвать базу администрирования, знание операционок и скриптов, умение читать несколько популярных языков, понимание принципа построения кода, как работают сертификаты и умение выделять проблемы. И важное качество - гуглить, находить необходимую для работы информацию.

Какие навыки пришли с опытом? У меня это умение находить общий язык с командой и подстраиваться под общий ритм. Со временем стало меньше страха и больше ответственности. Я даже побыл тимлидом и здесь понял, что не стоит никого критиковать, но важно отстаивать цели, разговаривать тет-а-тет, находить мотивацию.

Как долго выстраивается работа в команде, с чего начать и каких ошибок лучше не допускать?

В любой команде решающую роль играет авторитет. Если нет конфликта интересов, то всё выстраивается довольно быстро. Надо доверять команде и позволять каждому делать свою работу. Важно выстраивать открытый диалог и находить совместные пути решения проблемы. Потому что как неудача, так и успех - это заслуга всей команды. И нет ничего постыдного в том, чтобы обращаться за помощью.

С чего начиналась твоя карьера?

Начинал с работы электромонтера на заводе. Тогда понял, что не хочу работать руками, а хочу работать головой. Как DevOps начинал в проекте ePayments. Там после долгого застоя в развитии очень быстро учился. Там мне дали полный карт-бланш, и я развернулся: применял практики из умных книг, применял автоматизацию, мне удалось ускорить релизы с трех-четырех часов ручного труда до 10 минут после нажатия одной кнопки.

Какие проекты вдохновляют лично тебя?

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

Представь, что ты вернулся на 10 лет назад в прошлое, что посоветуешь себе?

Выучи уже этот английский, слабак!:)

А кем видишь себя еще через 10 лет?

Это самый стремный вопрос на всех собеседованиях. Сложно представить. Наверное, всё тот же я, ищущий ответы, но более авторитетный, с горящим взглядом и новыми идеями.

• Посмотреть расписание выступлений

• Узнать больше о спикерах

• Подробнее о конференции

Паша Финкельштейн разработчик, серийный спикер, автор и ведущий нескольких подкастов. На конференции Java Meeting Point он сделает доклад Spark: let's touch it, на котором познакомит участников с миром больших данных.

В этом интервью Паша рассказал, что ждет участников конференции, как он начал заниматься DevRel-активностями и что, по его мнению, должно быть в хорошем докладе.

Расскажи, чем ты занимаешься?

Я Developer Advocate в JetBrains, занимаюсь темой Big Data и дата-инжиниринга. Я пытаюсь рассказывать людям о том, как устроен мир Big Data, что там интересного, какие есть инструменты.

О чем будет твой доклад на Java Meeting Point?

Я расскажу, что такое большие данные и как они отличаются от маленьких. Разберемся, как работает Apache Spark, как устроен его API, и поймем, что ничего принципиально сложного в этом нет.

Кому будет полезно посмотреть доклад?

Полезно будет Java или JVM-разработчикам ровня Middle+ и тем, кому интересно узнать, как работает Apache Spark. Мы научимся писать простенькие пайплайны на этом фреймворке. Станет понятно как, например, взять и написать пайплайн обработки данных на Apache Spark или проанализировать данные в датасете.

Ты много занимаешься DevRel-активностями: выступаешь с докладами, вел подкасты. Как ты начал этим заниматься?

Мой друг Слава Семушин уехал работать в Чехию. Я не особенно умею поддерживать отношения на расстоянии, но Слава очень классный, с ним хотелось продолжать общаться. Однажды он написал: Слушай, давай запишем подкаст. Решили попробовать, и так родился подкаст Паша+Слава.

Раз в пару недель мы созванивались и говорили на околотехнические темы. Потом к нам присоединился еще один Слава Артемьев, с которым я работал в компании Домклик. Очень удобно не пришлось менять название подкаста. Так возникла моя первая публичность.

Потом появилась идея выступить на сцене, и я сделал доклад на Joker. В последствии этот доклад я переделывал 3 раза и выступил с ним 14 раз.

С тех пор я подсел на этот крючок и сделал десятки докладов. Со временем мне стало намного проще их готовить. Я могу подготовить выступление по теме, в которой я не разбираюсь за неделю, а теме, в которой разбираюсь за 2-4 дня.

Можешь посоветовать, как научиться так же быстро готовить выступления?

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

Что должно быть в хорошем докладе?

Он должен быть живым и интересным, в нем должны быть эмоции, шутеечки. В нем не должно быть слишком много мыслей, но те, которые есть, не должны быть заезженными. Неплохо, если информация из доклада применима на практике. Людям становится интереснее, когда они понимают, как они смогут использовать эту информацию.

Альтернативный вариант, это если доклад полностью теоретический. На такой люди придут вывернуть мозги. Так тоже можно, но сложно. Я один раз сделал доклад про внутренности Kotlin, людям не зашло.

Я люблю странные форматы: лайвкодинги, демки, парные доклады. Мне кажется, что у меня получается неплохо. Но не любить какой-то из этих форматов нормально, выбирайте для себя тот, который больше нравится.

Какой формат будет у твоего доклада на Java Meeting Point?

Это будет демо, на котором Java или JVM-разработчик на примере не очень больших данных сможет посмотреть, как работают большие. Мы посмотрим 5-6 слайдов и перейдем к программированию.

Дмитрий Александров инженер Oracle, Java Champion, участник и организатор многих IT-мероприятий. На Java Meeting Point 23 июня он расскажет про преимущества фреймворка Helidon, над которым работает.

Мы поговорили с Дмитрием и узнали, чем он поделится с участниками Java Meeting Point, каким был его путь в программировании и как он с товарищами организовал конференцию на 450 человек без опыта в крупных ивентах.

Расскажи, как ты начал заниматься программированием?

Я всегда любил кодить и занимался этим практически всю свою сознательную (может, даже и бессознательную) жизнь. Мне было лет 8 или 9, когда я начал. У моего поколения была такая штука Роботландия на 286-ых компьютерах. Можно было делать нехитрые задачки. И еще на этих же компах был установлен бейсик я в классе 6-м уже писал какие-то простые программы.

Можно сказать, что официально в программировании я с 2007 года тогда мне в первый раз заплатили за работу. За почти 15 лет работал в разных проектах: начинал как девелопер для аутсорса, затем успел поработать на вендора, на опенсорс.

Потом у меня был собственный стартап, который я успешно продал. Там была чистая Java, и это было своего рода счастье, потому что я сам выбирал, с чем работать. Но в этом проекте приходилось кодить по 12 часов в день, и в таком режиме выгораешь жестко. Только я решил отдохнуть, как меня срекрутили в T-Systems, и через неделю после выхода на работу я уже был в командировке в Германии. Перерыв получился всего в 4 дня.

Сейчас я работаю на Oracle. Работаю над замечательным опенсорсным фреймворком, который называется Helidon.

О нем и пойдет речь на Java Meeting Point, верно? Расскажи подробнее, о чем будет доклад.

На конференции я расскажу, что такое Helidon, и почему микросервисы стоит писать на нем. Дело в том, что большинство фреймворков, которые сейчас используются, как правило, обросли легаси, и чтобы их саппортить, нужно много стараться. А у нас все новенькое и модульное, Java 11+, много фишек, которые не все себе могут позволить, потому что у них есть как раз это легаси. А у нас его нет, поэтому у нас все круто.

Я попытаюсь рассказать так, чтобы участники конференции после доклада сразу же смогли попробовать Helidon в деле. Я очень люблю, когда люди могут начать сразу кодить, и для этого у нас есть все. Сам сетап этого фреймворка очень простой. С нами очень легко начать, потому что у нас есть отличные тулы, с ними можно и играться, и строить свой софт.

У Helidon есть большое преимущество это опенсорс. У нас лицензия Apache 2.0, а значит, все могут контрибьютить в проект. Это не реклама, а побуждение к тому, чтобы влиться в сообщество.

Ты много делаешь, чтобы развивать IT-сообщество: выступаешь сам, организуешь митапы и конференцию JPrime в Болгарии. Как ты стал спикером и организатором мероприятий?

Я выбрал для себя роль спикера, потому что очень боялся разговаривать на публике. Чтобы побороть этот страх, я просто начал выступать. Сначала собирался с друзьями, ребятами, которые тоже посещали IT-конференции, мы делали доклады друг для друга. У нас в Софии тогда было полумертвое коммьюнити, нас всего пять человек было.

Потом задумались о создании собственной конференции. По принципу, мы не знали, что это невозможно, мы взяли и сделали это. Написали основным игрокам в нашем регионе, что хотим организовать такое мероприятие, а через полтора дня они все к нам пришли с кучей денег и сказали: Делайте!

Мы даже не знали на тот момент, во что ввязываемся. Мы все кодили по 8-10 часов в день, и организация конференции стала дополнительной полноценной работой. Тем не менее, деньги нам дали в феврале, а в мае мы уже провели однодневную конференцию на 450 человек. После чего мы продолжили развиваться, к нам подтянулись известные спикеры, и до ковида мы уже провели двухдневное мероприятие на 1000 участников. Причем на него не только компании для сотрудников покупали билеты, но и просто отдельные люди. Но мы ничего на этом не зарабатываем: наша цель формировать коммьюнити.

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

Мы успели поездить по местным городам, разбудили локальные сообщества. Интересно, что после этого разные фирмы стали открывать офисы не только в столице, но и в других городах.

Здорово! Это похоже на то, что мы делаем в DINS: все наши мероприятия бесплатные и преследуют одну цель дать инженерам возможность для обмена знаниями и опытом. А что еще тебе нравится в этой деятельности?

Мне нравится этим заниматься, потому что я знакомлюсь с интересными людьми. Здесь нет материального интереса, главное, что я встречаю самых крутых программистов в мире. Я могу многому у них научиться, могу напрямую задавать вопросы это очень ценно.

Приходите на Java Meeting Point 23 июня, чтобы услышать доклад Дмитрия. Регистрация открыта на сайте конференции.

Василий Прокофьев разработчик Usetech в Рязани. На Java Meeting Point он расскажет о своем опыте использования реактивного программирования.

В этом интервью Василий поделился некоторыми деталями доклада и объяснил, почему подход, о котором пойдет речь, заслуживает внимания.

На Java Meeting Point ты расскажешь о реактивном программировании. Расскажи, почему ты выбрал именно такую тему?

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

Я приготовил примеры кода, на которых покажу разные тонкости реактивного программирования. Старался доклад подготовить так, чтобы понятно было каждому нужны только базовые знания функционального программирования, Java Core и Java 8.

Чему научатся участники конференции после твоего доклада?

Участники познакомятся с реактивным программированием на Java, научатся базовым навыкам работы с Рroject Reactor, а также разберутся с базовыми методами библиотеки.

Почему ты заинтересовался реактивным программированием?

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

Когда я только начинал вливаться в эту тему, читал, как сделать сервер для Minecraft на домашнем слабеньком компьютере. И получалось, если делать его стандартным способом, с помощью синхронного программирования, на сервер могли зайти 4 человека. При реактивном подходе 1,5 тыс. человек могли спокойно работать на этом сервере, и еще куча ресурсов оставалась на компьютере.

А еще эта тема очень активно используется у нас на проекте для банка, входящего в топ-3 по России. И реактивное программирование мы используем повсеместно: у нас могут проходить тысячи транзакций в секунду, и стандартным способом очень тяжело обработать такой массив информации.

В каких проектах нужно реактивное программирование?

Нужно помнить, что реактивное программирование создает и достаточно много проблем: сложности появляются при дебаге кода, при отлове ошибок и так далее. Поэтому, если проект маленький, то смысла делать его на реактивных рельсах нет. Зато, если вам требуется большая пропускная способность запросов, либо нужно обрабатывать действительно большие данные, этот подход будет как нельзя кстати.

Присоединяйтесь к конференции регистрация открыта на сайте.

Привет, Хабр!

На связи IT-конференция DUMP и программный комитет секции Фронтенд: Полина Гуртовая (frontend-разработчик в Evil Martians) и Егор Ходырев (тимлид, full stack-разработчик в Кнопке)

Кто согласен, что современный фронтенд это сложно? Ради чего мы мучаемся с настройкой Webpack? Почему реализация SSR требует писать столько кода, и нужен ли он нам вообще такой ценой? Кто виноват и что мы, как разработчики, можем сделать?

В этом году вместе с нашими спикерами постараемся максимально чётко ответить на эти и сотни других вопросов в секции Frontend.

Со своими идеями и решениями выступят:

Алексей Охрименко из Яндекс.Музыки выступит с докладом ''Трасси... что?''

Отладка приложения занимает 99% нашего времени. Кто-то пользуется Chrome DevTools, кто-то обходится обычным console.log, кто-то использует профайлеры. Зачастую этих инструментов более чем достаточно. Но есть еще один, не особо известный и популярный в JavaScript мире.
Трассировка процесс пошагового выполнения программы. В режиме трассировки программист видит последовательность выполнения команд и значения переменных на данном шаге выполнения программы, что позволяет легче обнаруживать ошибки.

В этом докладе: о плюсах и минусах трассировки, существующих инструментах, и поделюсь советами, которые мне помогали справляться даже с самой сложной кодовой базой.

Григорий Петров из Evrone представит доклад ''Нужен ли нам N(e/u)xt.js?''

Современный фронтенд это сложно. Если легаси проекты ограничены, то для новых приложений, кроме настройки Webpack и Babel, у нас есть HMR, SSR, code splitting, routing, кеширование, stream rendering и это, не считая фронтенд фреймворка и бэкенда, CI/CD и деплоя.

HMR "ломается" на приложениях сложнее hello world, настройку SSR в интернетах хором называют "адски сложной", ну, а роутинг, в уважающей себя связке фронт+бэк, можно неправильно организовать десятью конкурирующими способами.

Вся эта сложность породила новое направление jamstack, и такие решения, как Next.js и Nuxt.js "opinionated фреймворки", где все настроено за нас.

Григорий использует в докладе эти два фреймворка, чтобы рассказать об основных сложностях современной фронтенд-разработки и то, как мы можем с ними бороться: готовыми шаблонами, собственным кодом или новыми архитектурами приложений. Сложности увидим с позиции "почему так получилось?"

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

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

Андрей Гончаров из Hazelcast и тема его доклада, которая звучит так: Lifting state up is killing your app.

Слышали ли вы про lifting state up? Может ли одна из двенадцати ключевых концепций в официальной документации React приводить к плохой производительности? В рамках доклада мы сделаем простейший grid на React. Поэтапно разберем возникающие проблемы производительности. Увидим, что иногда и O(1) - это недостаточно быстро. Будем профилировать и рефакторить до тех пор, пока приложение не станет работать быстрее, чем вы успеете сказать React.

Леонид Семенов из InvestEngine выступит с докладом про Е2Е тесты в браузеры. Когда Cypress, а когда не очень.

Что делать если ошибки в проде смертельны, а релизы идут каждый день?
Как спастись от бессонных ночей, панической боязни сломать прод, и не страдать при этом от тестирования?

Ответов может быть много, но, кажется, что очевиден один автотесты!
Как внедрить автоматизированное сквозное тестирование?
О двух внедрениях, двух инструментах, одном путешествии, проблемах по пути и о самом пути вы тут и узнаете.

Роман Лысов из Semrush расскажет, ''Как создавать React компоненты, которыми будет приятно пользоваться''.

Проблема кастомизации компонентов и их использовании друг с другом всегда болезненна, и в компании Semrush решили эту проблему.
Доклад Романа основан на 4-х летнем опыте создания дизайн-системы для большого числа разработчиков. Он расскажет про практические приемы и паттерны для написания общих компонентов, которые помогут сделать ваш API компонентов более гибким, понятным и предсказуемым, что в итоге сэкономит многие человеко-часы на обслуживании в будущем.

Людмила Мжачих из Mail.Ru Group в докладе ''Как тестировать фронтенд без тестировщиков и спать спокойно'' объяснит, почему процесс разработки не может обойтись без багов и как сводить их к минимуму. Это становится возможным только когда разработка и тестирование начинают жить вместе.

Людмила поделится опытом скрещивания тестирования и разработки, о том, как команд автоматизировала регрессионное тестирование, какие инструменты использовала, с какими сложностями столкнулась и что из всего это вышло.

Полина Гуртовая из Evil Martians выступит с докладом ''RTC и Франкенштейн', в котором расскажет об особенностях использования WebRTC для боевых задач, опишет проблемы, которые поджидают разработчиков, и покажет способы их преодолевать.

Услышим и обсудим опыт наших спикеров 14 мая в форматах онлайн и офлайн. Полная программа конференции DUMP и билеты на сайте.

А пока спикеры готовятся к выступлениям, посмотри ТОП-3 выступлений секции фронтендеров с нашей прошлой конференции >>>

1. Виталий Дмитриев и его "Реактивное программирование. Как мыслить реактивно, а не проактивно"

2. Александра Шинкевич поделилась болью разработчика в докладе "Как внедрить стандарты разработки, чтобы никто не пострадал"

3. Вадим Макеев и 15 лет опыта: от создания и экспорта графики до оптимизации и вставки в его выступлении "Делайте из слона муху"

Обычно участники ждут от конференций полезных докладов с цифрами, фактами и только по делу. Мы учли это, взяли трендовые темы и пригласили опытных спикеров. Так получилась четкая и концентрированная программа секции Backend. Поговорим об актуальных сейчас технологиях и методах. Разберемся в серверной разработке без привязки к языкам программирования. А также поищем оптимальное решение задач, с которыми сталкивается большинство разработчиков бэка.

Ты только посмотри, какие спикеры нам в этом помогут!

Михаил Беляев из Прософт-Системы с докладом Проблемы embedded или как мы от sqlite ушли

При embedded разработке существует очень большая проблема весьма ограниченные ресурсы устройства, на котором выполняется твой код. В ходе разработки, когда запросы клиентов растут, а ресурсы embedded устройства на исходе, очень часто стандартные и проверенные решения не подходят. Разработчик сталкивается с выбором: или сказать, что наше устройство не может справиться с требуемыми задачами, или сделать нестандартный ход и выиграть. Вот именно об этом процессе перехода от использования SQLite к собственному хранилищу данных, которое позволяет читать и писать данные значительно быстрее, Михаил поведает другим разработчикам.

Андрей Цветцих из EPAM представит доклад Чистая Архитектура на практике. Вот что он рассказал нам о своем выступлении:

С момента выхода книги Дяди Боба Clean Architecture прошло уже достаточно времени. Кто-то ее прочитал, а кто-то только смотрел доклады на youtube. Но все эти доклады идейные. У их авторов обычно нет практического опыта создания больших проектов по данной архитектуре (как и запуска этих проектов в production). А все примеры слишком простые! На практике все равно остается много вопросов. Больше года назад мы начали 2 новых проекта, в которых применяли принципы, описанные в книге. Это корпоративные приложения на C# (API, backend). Enterprise, который еще не успел стать кровавым :) Но этого вполне достаточно чтобы получить первые результаты и поделиться опытом.

Роман Неволин из Контура выступит с докладом про Функциональные языки для бизнес-разработки

Функциональные языки зачастую воспринимаются как красивые и модные игрушки посмотреть и повертеть забавно, а вот в суровом энтерпрайзе им не место. Принято считать, что здесь лучше всего подходят проверенные годами, простые и надежные языки, такие как Java. Роман же с этим согласиться никак не может и постоянно пытается применить любимый функциональный язык F# - к очередной бизнес-задаче. На выступлении обсудим, как Роман это делает, зачем оно ему (и всем остальным) нужно, и какие именно грабли он успел собрать на пути.

Кстати, Романа можно будет услышать в нашем бесплатном стриме, о котором мы подробно рассказали здесь.

Евгений Пешков из JetBrains с докладом Клиентский HTTP в .NET: дорога по граблям от WebRequest до SocketsHttpHandler

На первый взгляд кажется, что отправить HTTP запрос это очень просто. Тем не менее, даже HTTP/1.1 достаточно нетривиален RFC на него содержит более 150 страниц, кроме того браузеры уже поддерживают HTTP/2 и HTTP/3. Это не оставляет никакого выбора: стандартный клиент в платформе должен быть реализован на высоком уровне.

На пути от .NET Framework 1.0 к .NET 5 клиентские API для работы с HTTP и его реализации претерпели множество изменений. В некоторых версиях они были удачными, в некоторых же провальными и явно временными.

В докладе Евгений расскажет о истории развития клиентского HTTP API в .NET, его особенностях, о миграции приложений с Framework на Core с их учётом. Также разберет некоторые хаки, полезные при работе с ним. Заглянем в NuGet и рассмотрим представленные в нём обёртки над HTTP API с точки зрения эффективности и кроссплатформенности.

Александр Поляков из Яндекса расскажет Как Яндекс.Афиша 2 раза переезжала на GraphQL

Этот доклад о том, как мы переписали API Я.Афиша с REST на GraphQL на node.js + Python. А затем, в рамках оптимизации, избавились от node.js + Python и переписали весь GraphQL на Java.

Разберемся со следующими вопросами:

почему мы выбрали технологию GraphQL

какие проблемы и задачи решали с ее помощью

расскажем и покажем, как эволюционировала наша архитектура

для каких команд и проектов подходит наше решение, а для каких нет и почему

А также дадим несколько практических советов по тому, как лучше всего начинать работать с GraphQL

Фагим Садыков из SpectrumData представит нам свой доклад Kotlin как основной язык разработки бэкенда и обработки данных

Kotlin язык противоречивый, с одной стороны, он уже занял респектабельную нишу "популярного языка", с другой стороны - многими воспринимается, как какой-то экзотический язык для Android или просто как любопытная игрушка на "попробовать".

В компании SpectrumData Kotlin используется как основной (и по факту единственный) продуктовый язык разработки на платформе JVM для самого широкого круга задач: работа с данными, реализация микро-сервисной архитектуры, реализация бэкенда. История успешного применения Kotlin в компании длится уже 4 года с версии языка 1.1. Для SpectrumData характерно полноценное применение в своей кодобазе всех возможностей и рекомендованных практик по данному языку.

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

Про Аспектно-ориентированное программирование на C# и .NET вчера, сегодня и завтра расскажет Денис Цветцих из Invent

Аспектно-ориентированное программирование (АОП) позволяет без дублирования кода добавлять инфраструктурный функционал вроде кеширования и логгирования на разные слои вашего приложения. И все это не меняя уже написанный код! Это очень мощная, удобная а также редко используемая техника. Отчасти это оправдано, 10 лет назад инструменты для реализации аспектов были не развиты, поэтому за АОП закрепилась слава подхода, используемого только энтузиастами. Но с тех пор мир изменился и сегодня АОП можно увидеть даже в веб-фреймворках, важно только уметь его распознать.

В своем докладе Денис поделится 10-летним опытом использования АОП на C# и .NET. Расскажет о подходах к реализации АОП, а также покажет, как менялись инструменты для разработки аспектов вместе с языком программирования и платформой. Естественно, он предложит наиболее оптимальный на сегодня вариант реализации аспектов. И вместе подумаем, какими хотелось бы видеть инструменты для разработки аспекты в будущем. Примеры будут на C# и .NET, но идеи доклада будут актуальны для любой платформы.

А под занавес программный комитет поставил Антона Шишкина из SKB LAB с докладом Рекомендации и фичи первой свежести . Здесь Антон расскажет про свой опыт построения рекомендательной системы от offline расчетов до online. И отдельно про то, как обеспечивается актуальность фичей для онлайн расчетов. Будут разобраны "допущения", благодаря которым фичи сохраняют свою "свежесть", при этом обеспечивается высокая доступность хранилища признаков.

Что будет происходить в остальных секциях, смотри в основной программе.

А здесь можно выбрать билеты в онлайн и офлайн формате.

Поддерживать высокое техническое качество кода прямая обязанность техлида. Но чтобы этого добиться, зачастую приходится доказывать начальству и заказчикам необходимость вкладывать в улучшение кода силы и время. Как сделать это, не стаптывая в бесконечных согласованиях железные башмаки и не стирая язык до мозолей? Об этом в своем докладе на конференции TechLead Conf 2020 Online рассказал консультант Better Life Company Алексей Дерюшкин.

Приведенные в статье примеры и истории помогут читателям выстроить баланс между продуктовыми и техническими задачами в диалоге с заказчиком и руководителями. А проверенные на практике советы правильно подготовиться к этому разговору.

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

Проблемы Алексея выглядели так:

• Бизнесу совершенно неинтересно, что находится под капотом и как сделать код лучше;

• Бизнес не разбирается в системе и не хочет это делать;

• Сам техлид не умеет вести переговоры;

Представьте ситуацию: техлид приходит к бизнесу с классной идеей (глупо же ходить с плохими идеями!) он придумал ее и знает, что она поможет. Иногда уже знает, что не реализовать ее не получится. Начинает разговор, но беседа не складывается.

Почему?! Потому что техлид говорил о каких-то технических вещах, а коллегам из бизнес-подразделений не интересно, как это работает. У них другие цели и задачи: как повысить конверсию, как привлечь больше людей, как сделать классный продукт. И технические детали им не интересны.

Из-за этого непонимания техлид не может продать идею. К тому же не все умеют уговаривать людей и просто продавать что бы то ни было. Недопонимание накапливается, и в итоге : Блин, да что с ними спорить? Я ему рассказываю, как надо сделать, а он ничего не понимает. Не буду этим заниматься в следующий раз!

У вас были ситуации, когда не получилось договориться с бизнесом? Если ответ да, контент ниже будет вам полезен.

Чем продажа идеи отличается от программирования?

Спойлер: ничем!

Есть три ключевые вещи, которые обязательно нужно сделать для того, чтобы успешно продать какую-то идею:

1. Подготовиться заранее. Если вы не обучались продавать свои идеи, то выйти и свободно вести разговор в нужном русле может быть сложно.

2. Взять готовый алгоритм. Люди уже очень давно (гораздо дольше, чем программируют), продают друг другу и материальные вещи, и идеи, и концепции. Зачем выдумывать велосипед, когда можно взять то, что уже работает?

3. Использовать эмоции. С ними тоже нужно уметь работать. Но чтобы сделать это правильно, лучше пойти на какой-нибудь тренинг по эмоциональному интеллекту.

Пример неудачной продажи

Техлид приходит к владельцу продукта:

• Привет! Я хочу добавить в этот спринт задачу по рефакторингу.

• Привет! Нет, в этот спринт мы должны выпустить новую фичу, мы уже обещали.

• У нас уже большой техдолг, мы все время торопимся и выпускаем фичи на костылях...

• Ну, делайте сразу нормально, кто ж мешает?

Это результат неподготовленного диалога.

Давайте разберем ошибки типичного диалога техлида с бизнесом:

• Птичий язык: владельцу продукта непонятно, о чем мы говорим;

• Готовые решения. Человек, которому мы продаем идею, не участвовал в ее разработке. Он не знает, почему эта идея ему нужна и как она связана с тем, чего он хочет добиться;

• Потребность убедить в своей правоте, а не помочь решить проблему бизнеса.

Итог закономерен: бизнес чувствует себя дураком, искренне не понимая, зачем нужно делать техдолг, когда можно сделать фичу.

Система продаж Джордана Белфорта

Есть замечательная цитата:

В фильме Волк с Уолл-стрит с Леонардо ДиКаприо прототипом главного персонажа является Джордан Белфорт один из самых известных продавцов и автор системы продаж.

На чем основывается его система? Джордан утверждает, что у вас купят идею (а на самом деле купят что угодно: телефон, автомобиль и т.д.), если есть 100% уверенность:

• В идее (продукте, предложении);

• В вас, как эксперте;

• В людях, которых вы представляете.

Рассмотрим бытовой пример: вам продают автомобиль.

• Идея 71%

Вы не совсем уверены, что автомобиль нужен вам как продукт. Но все же вам нужно ездить из пункта А в пункт В (на дачу, возить ребенка в школу).

• Эксперт 83%

Вы почти уверены в продавце. То есть человек, который показывает вам автомобиль в салоне, вызывает у вас доверие.

• Команда 78%

Вы также достаточно уверены в том, кого представляет продавец. Это может быть известная компания по продаже автомобилей или определенная марка. Например, вы уверены в том, что ес ли купите Mercedes, он не развалится в первый день, и не уверены в том же самом с АвтоВАЗом.

Если во всех трех пунктах ваша уверенность 100% или близко, то скорее всего, автомобиль вы купите.

В нашем случае, когда техлид идет с кем-то разговаривать, он представляет не компанию, а свою команду. Может быть, в голове своего собеседника он представляет программистов в целом, и с этим сложно будет бороться.

Вернемся к примеру с автомобилем, и рассмотрим вариант, когда вы не купили машину:

• Идея 0%

• Эксперт 100%

• Команда 100%

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

Если вы уверены, что автомобиль вам нужен, но при этом вы не доверяете продавцу вам кажется, что он хочет вас надуть или впарить 100500 опций, то конкретно у этого человека вы не купите:

• Идея 100%

• Эксперт 0%

• Команда 100%

В случае, когда вы не хотите связываться с АвтоВАЗом, и LADA Granta не ваша мечта, будет так:

• Идея 100%

• Эксперт 100%

• Команда 0%

То есть если даже один параметр будет не 100%, а 30-40% и ниже, вы не убедите человека купить автомобиль. А на месте техлида не продадите идею сделать тесты, что-то автоматизировать или провести рефакторинг.

Важный момент по поводу 100 баллов из 100. Вы можете только предполагать, каковы цифры на самом деле. Странно было бы на переговорах говорить человеку: А ну, скажи мне: от 0 до 100, насколько ты во мне уверен?. Это просто метафора, а не цифры, которые можно использовать в разговоре.

Как добиться уверенности на 100\100\100?

Идти по алгоритму.

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

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

Алгоритм продажи чего угодно, в том числе идей

Первые четыре секунды

Это время в разгоре самое важное. Если вы с человеком не знакомы, это время будет потрачено на создание первого впечатления. Но даже если вы знаете своего собеседника или постоянно работаете с ним, первые четыре секунды зададут общую эмоцию на весь разговор. Если вы сходу создадите неприятное впечатление или опоздаете, разговор во многом будет потерян.

Будьте доброжелательны и энергичны, но не слишком: не как персонаж из Маппет-шоу. Чуть-чуть энергичней, чем собеседник уже очень хороший уровень.

Кратко изложите, зачем пришли (позвонили, назначили встречу). Человек, скорее всего, чем-то занят, это элементарная вежливость.

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

Раппорт

Кроме того, важно в течение всего разговора поддерживать доверительные отношения с тем, с кем говорите: не вступать в конфронтацию, не валять дурака и т.д.

Отсутствие раппорта очень хорошо описывает картинка:

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

Сбор информации

Сбор информации важно делать заранее. Скорее всего, по ходу беседы вы не сможете этим заняться. Вам нужно заблаговременно подумать о человеке. Может быть, спросить у него напрямую или поинтересоваться у коллег, что его волнует, какие у него боли сейчас в его работе, каких он ждет выгод. То есть узнать, чего он хочет добиться, какие цели и задачи ставит (или ему ставят цели и задачи). Продажа идеи должна идти от потребностей или проблем покупателя.

Давайте посмотрим на три пункта:

• Боли ярко окрашенные негативные эмоции;

• Выгоды позитив;

• Цели и задачи более нейтральные вещи.

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

Основная презентация и предложение о покупке

Когда мы рассказываем о своей идее, обязательно нужно говорить на языке того человека, с кем мы общаемся. То есть на языке бизнес-целей!

Строим презентацию по схеме:

• Как ваша идея поможет собеседнику?

Не почему это классная идея, не почему вы думаете, что она хороша, а почему она поможет собеседнику. Здесь вам поможет предыдущий этап сбора информации.

• Визуализируем ужасное будущее;

• Визуализируем хорошее будущее;

• Если это нужно, даем МИНИМУМ технических деталей;

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

• Называем цену.

Цена в кавычках, поскольку это может быть буквальная цена, или неделя работы. В любом случае (купить сервер и заплатить за это деньги или купить идею автоматизировать что-то и заплатить временем работы команды) алгоритмы продаж работают и во время договоренностей. Потому что любая договоренность, когда вы принесли какую-то идею, подразумевает действие и с обратной стороны. Человек в метафорическом смысле платит вам чем-то: своим вниманием, временем, тем, что ему придется выучить что-то новое. Не всегда речь идет о деньгах, но все-таки собеседник что-то дает вам взамен на вашу идею. Вы должны понимать цену этого.

Очень хорошая фраза, которая отдает мячик вашему собеседнику после презентации:

Мне кажется, это хорошая идея. Что скажешь?

Таким образом вы даете собеседнику возможность высказаться. И, слушая его, можете понять, насколько он уверен в идее, в вас и т.д.

Перенаправление на рост уверенности.

Если человек не убежден, мы перенаправляем разговор на уверенность. Например, вы сделали предложение: Давай что-то автоматизировать, а собеседник отказывается: Не хочу, нет времени (ресурса). Его возражение это ширма. На самом деле он не уверен либо в вас как в эксперте, либо в самой идее, которую вы принесли, либо в программистах вашей команды, в целом. Поэтому идет перенаправление на рост уверенности. Вам стоит еще раз пройтись по этим пунктам, разобраться, почему он не уверен. А после починить эту уверенность, а не ширму, которой он прикрывается, говоря о том, что нет времени, ресурсов и т.д.

• Спросите, что смущает, и развейте страх

Если у вас не купили, значит, нет уверенности. Надо выяснить, где провал, почему 50% вместо 100%. И постараться это починить. Возможно, собеседник скажет напрямую:

• Я не уверен, что это поможет.

Об идее, скорее всего, можно говорить прямо. Но вряд ли человек скажет:

• Я тебе не доверяю, как специалисту.

Или:

• Мне кажется, твоя команда не справится.

Поэтому если собеседник в диалоге сразе не согласился с вами, значит, он в чем-то не уверен, и этот вопрос можно поднять и обсудить. Но, возможно, вы обсудите идею напрямую и при этом он все равно не согласится. В этом случае, проблема в том, что он либо вам не доверяет, либо вашей команде. Этот момент нужно чинить не прямо здесь и сейчас, на встрече, а контекстно, на протяжении всей работы. Если вы понимаете, что последние три месяца не выполнили ни одного обещания, нужно сначала научиться выполнять обещания, а потом уже приходить с новыми идеями. Скорее всего, без этого вы не сможете их продать.

Снижение порога действия

Бывает, что человек во всех трех шкалах уверен на 100%, но при этом ничего не делает. Почему так происходит? Есть такое понятие порог действия нужно, чтобы сама покупка была легкой. И под конец взаимодействия мы должны сфокусироваться на нем, чтобы человеку было легко войти в сделку, принять идею и начать что-то делать.

Итак, на предыдущем этапе во всех трех пунктах набралось по 100 баллов, мы молодцы, идея классная, она нравится нашему собеседнику. Однако ему нужно совершить очень много действий, чтобы реализовать озвученную идею. Например, вы предложили ему что-то автоматизировать, но для этого он, дорогой ваш владелец бизнеса, должен подать заявку, чтобы она прошла через бюрократическую систему. Ему проще сказать: Да ну его на фиг! и убежать, чем соглашаться на такую длинную историю.

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

• Просто кивни, мы все сделаем сами.

• Тебе ничего не надо будет делать.

• Мы уже попробовали, и вот результат...

Последний вариант идеальный. Вы делаете большую часть работы за него. Или, как минимум, делаете так, чтобы собеседнику не пришлось слишком много об этом думать.

Усиление боли

Это визуализация страшного будущего, в котором ваш собеседник не согласился на вашу идею:

• Если ничего не поменяется, то...

• Знаешь ли ты, что будем, если мы этого не сделаем?

• Через год станет

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

Закрытие сделки

Это опять передача мяча собеседнику:

• Что дальше?

• Ну что, попробуем?

• Ты согласен, что...?

Это прямые вопросы, которые вы задаете собеседнику: Ну, как? Берем работу в следующий спринт? Ставим в план на следующий месяц?. Но эти вопросы часто просто забывают задать. Мы вроде бы обсудили идею и просто ждем, когда человек сам скажет: Ладно, давай. Я буду делать то-то и то-то.

Нет, пожалуйста, возьмите инициативу на себя и задайте вопрос: Ну как, работаем дальше?.

Пример

В 2015 году в одной из команд Алексей работал как техлид и на этапе подготовки он узнал о том, что сроки выхода в продакшн жестко зафиксированы, а в SLA на починку ошибки в продакшн выделено всего три дня.

То есть у владельца продукта есть две проблемы: жестко зафиксированы сроки и выхода в прод, и на починку багов. Если что-то из этого нарушается, владельцу продукта будет очень плохо. Поэтому продажа идеи была реализована через боль.

Диалог был примерно такой:

• Привет! Я хочу обсудить одну техническую задачу, которая может ускорить время разработки задач и починки ошибок. Есть 10 минут, чтобы обсудить сейчас?

• Давай.

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

Дальше идет презентация:

Смотри, сейчас у нас нет автотестов, и каждую фичу перед выпуском мы тестируем руками, ЭТО ДОЛГО. Я с ребятами УЖЕ ПОСЧИТАЛ, что если мы закроем 15% функционала тестами, то разработка каждой новой фичи УСКОРИТСЯ НА 2 ДНЯ. Благодаря этому мы сможем сделать на 10 фич больше до дедлайна. Мы все сделаем сами, надо просто взять в этот и следующий спринты задачи по разработке тестов. За этот месяц мы сделаем меньше фич, НО зато потом каждую будем делать быстрее. А еще это поможет быстрее чинить баги.

Что мы здесь видим? Во-первых, в презентации были указаны конкретные цифры. 15% функционала, 2 дня и 10 фич.

Во-вторых, был минимум технических деталей, а конкретно одна: 15% функционала надо закрыть. Цифра на самом деле не важна это может быть и 10%. Владельцу продукта важнее, что разработка новой фичи ускорится, или что баги будут чиниться быстрее.

В третьих, разговор был не про фреймворк тестирования и не про то, как будут проводиться тесты. Говорили про боль владельца продукта, а продавалась выгода от автотестов и новых фич.

Дальше называем цену: Месяц будем делать меньше фич, но потом снова возвращаемся к выгоде (к хорошему будущему) с отсылкой на две боли клиента.

В оригинале презентация была долгой, встреча на час. И одна из фраз, которая там прозвучала:

• Представь, если мы будем и дальше также тестировать вручную, то с ростом функционала на тесты будет уходить все больше времени. Сейчас эту фичу мы делаем за 3 дня, а через полгода такую же будем делать 5 дней.

• Что скажешь?

Это пример, как можно по такому алгоритму проводить продажи идей.

Полезные фишки

Есть полезные фишки, которые помогут в любом диалоге:

• НО наоборот;

В предыдущем примере как раз используется эта фишка: мы сделаем меньше фич, НО зато потом каждую будем делать быстрее. Обычно мы говорим: Я сделал что-то хорошее, НО будет вот это и вот это плохо. То есть сначала обговариваем позитивные моменты, а потом идут НО и неприятные вещи. Поменяйте их местами: если есть что-то неприятное, сначала расскажите о нем, а потом о хорошем: Сейчас сделаем на 20% меньше фич, НО потом мы будем эти фичи печь как пирожки.

• Потому что;

Если вы просто говорите: Так, дорогой мой бизнес, надо сделать рефакторинг и точка!, вам ответят: Да иди ты со своим рефакторингом! Почему? Вы не объясняете собеседнику причины. Людям гораздо легче согласиться с вами, когда они понимают, зачем вы это делаете. бъясните, зачем вы продаете идею (возвращаемся к целям и выгодам). Если вы пришли с идеей без объяснений, почему это важно сделать, то ваш собеседник почувствует себя обескураженным, не зная нужных ему деталей. Объясняя, вы выравниваете диалог.

• Визуализация;

В продаже идеи очень важно визуализировать будущее, в которое люди попадут, реализовав то, что вы преподнесли, или же наоборот, отказавшись от вашего предложения. Это стоит сделать для того, чтобы вызвать эмоции, через которые человек либо согласится, либо откажется.

• Двойная петля;

Если вы видите, что собеседник сомневается (сначала у него есть один аргумент против, потом появляется другой, третий), скажите ему прямо: Мне кажется, что ты не уверен в идее, которую я принес. Расскажи, почему?. Так он попадает в двойную петлю: либо говорит: Нет-нет, я уверен, и начинает сам себе продавать уверенность, либо говорит: Да, я не уверен, и тогда дает вам аргументы, с которыми вы сможете работать.

• Прямолинейность.

То, что вы честно и открыто ведете диалог, всегда подкупает.

Подводя итог

Итак, чтобы договориться, нужно выполнить несколько важных условий.

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

Кроме того, вы должны добиваться 100% уверенности по трем пунктам: в продукте, который продаете, в вас, как эксперте, и в людях, кого представляете.

Думайте о том, как помочь клиенту, а не как продать идею. И, наконец, следуйте приведенному в статье алгоритму. Его будет достаточно для того, чтобы ваши переговоры завтра или в следующий понедельник подросли в плане качества.

TechLead Conf 2021 пройдет 30 июня 2021и 1 июля 2021 в московской Radisson Slavyanskaya. Расписание можно посмотреть здесь.

Билеты на конференцию вы можете приобрести уже сейчас. Спешите: 1 мая цена станет выше!

ПЛИС-культ привет, FPGA хаб!

FPGA-движ, хоть и не быстро, но набирает свои обороты и проведение уже второй за полгода встречи ПЛИСоводов, прошедшей в формате конференции, это подтверждает. Мы пересмотрели формат конференции, учли приобретенный ранее опыт организации / проведения мероприятия и также постарались прислушаться к вашим пожеланиям и отзывам. В итоге у нас получилось: два типа докладов (суммарно их было 9 ), хакатон и 3 викторины с призами.

Я пытаюсь делать движ по FPGA направлению последние 4 года и очень рад, что находятся те, с кем мне по пути. К середине прошлого года удалось собрать "критическую массу" попутчиков, вполне достаточную для проведения каких-либо очных мероприятий. Конечно, до уровня Юрия Владимировича Панчула еще очень и очень далеко, но "кцелидвижетсятот,ктохотябыползёт".

Последняя суббота апреля

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

Учитывая все выше написанное, вторая конференция состоялась 24 апреля 2021 года в ИЦ "Сколково".

Зальные проблемы

С учетом посещаемости того года нам выделили зал на 50 человек. Мы должны были собраться в ИЦ "Сколково" - Амальтея - Капсула номер 3. Предварительно в пятницу 23 апреля я провел без малого 4 часа в подготовке оборудования, настройке трансляции, проверке звука, понимания какие кнопки на пульте надо было крутить, чтобы сделать небольшой тюнинг во время прямого эфира и тд (особенно учитывая опыт по трансляции с первой конференции). Зная, что звук будет являться главной проблемой, я 10 раз все перепроверил, провел тестовую трансляцию с парой человек из комунти и со спокойной душой поехал домой.

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

Поскольку зал нам выдали бесплатно, да еще и в субботу, то мы были там полностью на птичьих правах. Соответственно, я начал расспрашивать за любое другое свободное помещение, в которое бы поместилось 50-60 человек. Несказанно повезло, что была свободна капсула 1 - но я ее в глаза не видел, не знал какое там оборудование, как им пользоваться, но вариантов не было. Пришлось согласиться и выехать с утра пораньше в Сколково, что бы хоть как-то настроиться "на скорую руку".

Огромное спасибо Петру Рогачеву, он проторчал в ту пятницу до самого позднего вечера в Сколково, чтобы к утру наше помещение было полностью готово. Так сказать он перенес настройки одной капсулы в другую.

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

Спонсоры

В этом году повезло и с тем, что один из участников/докладчиков первой конференции предложили оказать спонсорскую поддержку. Спасибо компании Эремекс, SK Tools и немалому числу информационных партнеров, оказавших помощь в распространении информации о мероприятии. Все ссылки на их ресурсы вы найдете в презентациях докладчиков (см Программу конференции).

Программа конференции

Программа конференции была действительно насыщенной: 5 докладов по 50-60 минут, 4 доклада по 20-30 минут, 3 викторины минут по 10. Между докладами 10 минут перерыв и один большой перерыв на час. При этом вся конференция продолжалась более 9 часов.

Вместе с программой я выложу ссылки записи / нарезки докладов и ссылки на скачивание презентаций. Все видео собраны в отдельный плейлист на YouTube. Там же вы найдёте и полную 9-ти часовую запись с таймкодами

Программа:

10:00 Открытие конференции

10:10 - 11:00 Beyond HLS. Задачи архитектора, которые может решать экосистема разработки / Буровский Павел

11:10 - 11:20 Возможности отечественного САПР проектирования электроники Delta Design / Никита Малышев

11:20 - 12:10 Роль лексического и синтаксического анализа в маршруте разработки проекта ПЛИС/ Варганов Артем

12:10 - 12:20 Викторина #1

12:30 - 12:50 Платформа для on-line обучения схемотехнике на интерактивных схемах / Гнитеев Николай

13:00 - 13:50 Скриптовая среда для работы с периферией ПЛИС с использованием boundary-scan + демо / Иванов Алексей

13:50 - 14:00 Викторина #2

14:00 - 15:00 перерыв

15:00 - 15:20 Искусство отладки FPGA / Дыдыкин Сергей

15:30 - 16:20 Генерация HDL кода из моделей MATLAB/Simulink / Шидловский Дмитрий

16:20 - 16:30 Викторина #3

16:40 - 17:00 Опыт создания виртуальной лаборатории для проектирования на ПЛИС в МИЭМ НИУ ВШЭ / Романов Александр

17:10 - 18:00 Реализация криптоалгоритмов на ПЛИС / Мурзинов Дмитрий

18:10 - 18:30 Результаты хакатона, награждение победителей

18:30 - 19:00 Итоги конференции

Вопросы викторин

Во время мероприятия мы провели три небольших викторины среди участников как онлайн трансляции, так и участников в зале. Для её проведения я использовал телеграм бота QuizBot, а сами викторины публиковались в ранее созданном отдельном канале конференции. Желающие проверить свои FPGA знания на простеньких вопросах первой викторины и свои знания по истории ПЛИС могут пройти викторины самостоятельно: ссылка на первую викторину и ссылка на вторую викторину. Пока ответить правильно на все вопросы второй викторины ни кому не удалось :-)

Хакатон

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

География очной аудитории

Учитывая ограниченность предоставленного помещения, в Сколково в этом году приехали почти 60 человек: Воронеж, Рязань, Калуга, Ярославль, Дубна, Москва, Санкт-Петербург, Нижний-Новгород, Саров, Челябинск, Петрозаводск, Зеленоград, Долгопрудный, Раменское.

Онлайн трансляцию смотрели участники из России, Польши, Беларуси, Украины, Казахстана, Эстонии.

Приятно, что интерес к мероприятию растет, и охват аудитории становится с каждым разом немножко больше.

Опрос

После мероприятия мы решили провести небольшой анонимный опрос, который бы показал интересы FPGA разработчиков в плане используемых языков, направлений разработки и общего впечатления о мероприятии. Если вы хотите дополнить статистику опроса, то это можно сделать по ссылке. Опрос строго анонимный

PS в конце статьи есть также хабр-опрос

Когда следующая FPGA конференция?

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

Мы опять встретимся в Москве, но если найдется хотя бы 5 докладчиков в Санкт-Петербурге, то мы проведем встречу и в северной столице тоже. Все зависит от вас ;-)

Ссылка для предварительной регистрации на третью конференцию FPGA разработчиков FPGA-Systems 2021.2

PS: ищем ещё варианты с местом проведения? Мб кто-то прочитает и скажет "ого да я могу предложить этим ребятам хороший вариант"

--

В заключении хотел бы выразить благодарность помогаторам, докладчикам, участникам конференции и FPGA комьюнити за поддержку. Без вас бы это мероприятие не состоялось.

Привет Хабр! Мы выложили на YouTube видеозаписи докладов митапа ИТ-сообщества в разных компаниях 21 апреля. В онлайн-формате эксперты ИТ-кластера Ростелекома, а также наши коллеги из Альфа-Банка, Fleetcor, Райффайзенбанка рассказали, как создавать и развивать профессиональные сообщества в ИТ-компаниях.

Пропустили мероприятие? Делимся главными тезисами докладов, а ещё видео и презентациями спикеров. В хронолическом порядке.

#1 Делаем сложное возможным Татьяна Егорова(Ростелеком)

Открывающий доклад митапа про историю запуска Гильдии аналитиков Ростелекома с комментариями её создателя. О предназначении гильдии аналитиков, как её строили, с какими трудностями сталкивались и как их преодолевал.

Скачать презентацию

#2 Что сотрудники могут изменить под эгидой Гильдии развития ИТ Полина Самсонова (Ростелеком)

В Ростелекоме действует ещё одно профессиональное комьюнити гильдия развития ИТ. Её создатель Полина Самсонова активный генератор и реализатор идеи объединения сотрудников в круги рассказывает о том, как объединять неравнодушных коллег в сообщества, которые меняют процессы в компании на длинной дистанции.

Скачать презентацию

#3 Рабочие группы и их вклад в развитие системного анализа Алексей Лобзов (Альфа-Банк)

Алексей регулярный спикер митапов и образовательных проектов для системных аналитиков. Вас ждёт знакомство с внутренними проектами Альфа-Банка по развитию системных аналитиков, а после небольшой теоретической части Алексей покажет на реальном кейсе, в чём преимущества и недостатки рабочих групп.

Скачать презентацию

#4 Карьерные диалоги Наталья Пешкова (Райффайзенбанк)

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

Скачать презентацию

#5 Внутренние обучения как способ повышения экспертизы сотрудников Анастасия Груздева и Светлана Михеева (Альфа-Банк)

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

Скачать презентацию

#6 Эти неловкие вопросы про комьюнити Татьяна Такташева (Fleetcor)

Резюмирующий доклад митапа в формате глупых вопросов:
- Как организовать комьюнити?
- Как найти ЦА?
- Какую периодичность встреч выбрать?

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

Скачать презентацию

Вместо заключения

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

Полную видеозапись митапа смотрите на YouTube по ссылке.