Для тех кто любит запрыгнуть в последний вагон, и с пользой провести предстоящие выходные приглашаю на тренинг китайская ручка.
#анонс #китайскаяручка #тренинг #сбортребований #требования
Тренинг позволяет в игровой форме аналитику отследить типичные ошибки и понять, как их нивелировать на практике, что помогает повысить качество результата своей работы.
-------------------------------
Тренинг состоит из 4 блоков:
✅ Блок 1. Команда аналитиков проводить интервью с заказчиком и фиксирует требования.
Происходит согласование требований с заказчиком и исполнителем. В конце мы получаем продукт.
✅ Блок 2. Разбираем, как повысить качество требований, для этого их разбиваем на уровни. Понимаем где требование, а где описано решение. Вносим изменения.
✅ Блок 3. Описываем нефункциональные требования к продукту. Разбираем, атрибуты качества требований.
✅ Блок 4. Обсуждаем, как можно ДОвыявить требования, с помощью Story mapping, Impact mapping. Разбираем нюансы работы аналитика в гибких подходах к разработке ПО.
-------------------------------
💪Кому подойдёт тренинг?
Тем кто хочет освоить специальность ИТ-аналитика. Или тем кто хочет разобраться в том, кто такой ИТ-аналитик (часто это полезно менеджерам проектов, HR-специалистам). Вы сможете за 8 часов увидеть цикл разработки от сбора требований, до реализации решения. Поймёте место аналитика в процессе и какое влияние результат его работы оказывает на конечный программный продукт.
Если вы начинающий аналитик с опытом от 1 до 3 лет, вам точно будет полезно поучаствовать в тренинге. Со стороны посмотрите на свой опыт, увидите какие типичные ошибки вы допускаете, определите зону ответственности и роста аналитика, поймёте как структурировать свою работу.
Если вы аналитик с опытом от 3 до 5 лет, тренинг поможет систематизировать свои знания, увидеть тонкую грань между требованием и решением.
Если вы ведущий аналитик или тим лид анализа, вы сможете понять, как стоит выстраивать работу команды, чтобы повысить качество результата работы аналитиков. Если вы формируете команду анализа, то сделаете для себя выводы, на что стоит обращать внимание в первую очередь, именно вам, при подборе специалистов.
-------------------------------
✔️Формат тренинга - онлайн, выходные, 2 дня по 4 часа (с 10 до 14 по Москве).
Команды участников тренинга будут работать над продуктом, это ручка. Мы специально берём знакомый всем предмет, чтобы наглядно показать, типичное поведение заказчика, ошибки аналитика, и сделать выводы что можно изменить, добавить в свой арсенал работы для повышения качества результата анализа.
-------------------------------
Все материалы и записи тренинга остаются у вас в доступе, вы всегда можете вернуться к ним.
-------------------------------
Если остались вопросы пишите их ниже в комментариях 👇
Чтобы записаться на тренинг оставляйте заявку на странице ➡️
https://sup.expert/pen
#анонс #китайскаяручка #тренинг #сбортребований #требования
Тренинг позволяет в игровой форме аналитику отследить типичные ошибки и понять, как их нивелировать на практике, что помогает повысить качество результата своей работы.
-------------------------------
Тренинг состоит из 4 блоков:
✅ Блок 1. Команда аналитиков проводить интервью с заказчиком и фиксирует требования.
Происходит согласование требований с заказчиком и исполнителем. В конце мы получаем продукт.
✅ Блок 2. Разбираем, как повысить качество требований, для этого их разбиваем на уровни. Понимаем где требование, а где описано решение. Вносим изменения.
✅ Блок 3. Описываем нефункциональные требования к продукту. Разбираем, атрибуты качества требований.
✅ Блок 4. Обсуждаем, как можно ДОвыявить требования, с помощью Story mapping, Impact mapping. Разбираем нюансы работы аналитика в гибких подходах к разработке ПО.
-------------------------------
💪Кому подойдёт тренинг?
Тем кто хочет освоить специальность ИТ-аналитика. Или тем кто хочет разобраться в том, кто такой ИТ-аналитик (часто это полезно менеджерам проектов, HR-специалистам). Вы сможете за 8 часов увидеть цикл разработки от сбора требований, до реализации решения. Поймёте место аналитика в процессе и какое влияние результат его работы оказывает на конечный программный продукт.
Если вы начинающий аналитик с опытом от 1 до 3 лет, вам точно будет полезно поучаствовать в тренинге. Со стороны посмотрите на свой опыт, увидите какие типичные ошибки вы допускаете, определите зону ответственности и роста аналитика, поймёте как структурировать свою работу.
Если вы аналитик с опытом от 3 до 5 лет, тренинг поможет систематизировать свои знания, увидеть тонкую грань между требованием и решением.
Если вы ведущий аналитик или тим лид анализа, вы сможете понять, как стоит выстраивать работу команды, чтобы повысить качество результата работы аналитиков. Если вы формируете команду анализа, то сделаете для себя выводы, на что стоит обращать внимание в первую очередь, именно вам, при подборе специалистов.
-------------------------------
✔️Формат тренинга - онлайн, выходные, 2 дня по 4 часа (с 10 до 14 по Москве).
Команды участников тренинга будут работать над продуктом, это ручка. Мы специально берём знакомый всем предмет, чтобы наглядно показать, типичное поведение заказчика, ошибки аналитика, и сделать выводы что можно изменить, добавить в свой арсенал работы для повышения качества результата анализа.
-------------------------------
Все материалы и записи тренинга остаются у вас в доступе, вы всегда можете вернуться к ним.
-------------------------------
Если остались вопросы пишите их ниже в комментариях 👇
Чтобы записаться на тренинг оставляйте заявку на странице ➡️
https://sup.expert/pen
sup.expert
"Китайская ручка"
Аналитик исследует проблему и проектирует решение на языке требований.
Интересно как много точек зрения на работу аналитика. И год за годом постоянно идут обсуждения по кругу, что должен или не должен делать аналитик. Когда я говорю, что аналитик проводит исследование, анализ проблемы, чтобы дальше перейти к описанию решения на языке требований, появляются альтернативные мнения.
Например, заказчику самому виднее, какое ему нужно решение и аналитик, просто сопровождает заказчика к результату, этого решения. Описывает. Хочется сказать, что становится тех писателем, секретарём или решателем.
Насколько подобная ситуация правдива?
Можно ли так работать аналитику?
И да, и нет, и с моей точки зрения, это ещё и вопрос компетенций аналитика и самого заказчика. Кто на что способен и в каких условиях оказалась команда и заказчик.
Если заказчик так уверен в своём решение, даже если оно ошибочное, проще сделать, чем спорить или убеждать.
И конечно вопрос ресурса, денег, времени и уровня критичности решаемой проблемы.
Чаще всего действительно заказчик приходит с решением в команду и команда это решение реализовывает. Да, и я так делала, мне принесли в клюве, я пошла и сделала. Могла повозмущаться или перепроверить решение, что когда ты рядовой аналитик сложно влиять на решение.
А ещё мне нравится фраза "скажите, что мне сделать, я сделаю"... Такое веяние социального давления, проще подстроиться, чтобы всем было хорошо. А когда задаёшь вопросы, копаешь, роешь, вызываешь негатив, эмоции, а это всё очень сложно. Хочется же попроще, правда?)
Зачем вообще исследовать проблему?
✅1.Элементарно понимать, что мы делаем, зачем и главное, как мы будем это сдавать заказчику.
✅2.Не знаю свежую статистику % успешных проектов, но от 80 до 90% айти проектов, продуктов провальны, по причине того, что мы делаем, то что никому было не нужно, никто это не просил, или не просил в таком виде.
✅3.Рост количества переделок, "не попадания в цель", становится критичным или дорогим. Тут зависит от сферы, часто B2C сервисы, могут позволить себе клепать быстро, чтобы захватить рынок или протестировать гипотезу. В B2G, B2C, в сложном Enterprise у нас нет права совершать множество ошибок и смотреть конечный результат, а потом разводить руками - "не шмогла, не шмогла..."
✅4.Так хочется сразу перейти к решению. Это в том числе наши любимые когнитивные искажения, нашему мозгу проще перейти в ту область, где мы себя чувствуем увереннее и понимаем о чем идёт речь. Подмена понятий, тоже сюда. Упростить и сразу говорить о решение. Эмоций больше, приятнее и есть ощущение действия, результата.
И вот потратив время на исследование проблемы, аналитик приступает к описанию решения на языке требований. И тут это отдельное искусство описать так, чтобы у команды была возможность выбрать технологии, оптимальные, эффектные реализации. Не прибивая всё гвоздями.
И будем реалистами, работа аналитика правда сложная, наши айти проекты правда сложные, и наши заказчики люди с множеством мыслей, эмоций, своим мнением, опытом, и к ним нужно искать подход, а работа с людьми это тяжело.
Как бы не хотел аналитик откреститься от заказчика, потому что, часто общение с заказчиком это сложно, ресурсоемко, и нужно быть психологом, коучем, чтобы найти контакт. Но горькая правда в том, что приходится прокачивать себя в переговорах, коммуникации и управление ожиданиями заказчика, чтобы исследовать проблему и только потом переходить к решению, которое должно помогать заказчику получать ожидаемый эффект.
Вот такие сегодня местами сложные мысли)
#мысливслух #сбортребований #исследование #проектирование #правдажизни
Интересно как много точек зрения на работу аналитика. И год за годом постоянно идут обсуждения по кругу, что должен или не должен делать аналитик. Когда я говорю, что аналитик проводит исследование, анализ проблемы, чтобы дальше перейти к описанию решения на языке требований, появляются альтернативные мнения.
Например, заказчику самому виднее, какое ему нужно решение и аналитик, просто сопровождает заказчика к результату, этого решения. Описывает. Хочется сказать, что становится тех писателем, секретарём или решателем.
Насколько подобная ситуация правдива?
Можно ли так работать аналитику?
И да, и нет, и с моей точки зрения, это ещё и вопрос компетенций аналитика и самого заказчика. Кто на что способен и в каких условиях оказалась команда и заказчик.
Если заказчик так уверен в своём решение, даже если оно ошибочное, проще сделать, чем спорить или убеждать.
И конечно вопрос ресурса, денег, времени и уровня критичности решаемой проблемы.
Чаще всего действительно заказчик приходит с решением в команду и команда это решение реализовывает. Да, и я так делала, мне принесли в клюве, я пошла и сделала. Могла повозмущаться или перепроверить решение, что когда ты рядовой аналитик сложно влиять на решение.
А ещё мне нравится фраза "скажите, что мне сделать, я сделаю"... Такое веяние социального давления, проще подстроиться, чтобы всем было хорошо. А когда задаёшь вопросы, копаешь, роешь, вызываешь негатив, эмоции, а это всё очень сложно. Хочется же попроще, правда?)
Зачем вообще исследовать проблему?
✅1.Элементарно понимать, что мы делаем, зачем и главное, как мы будем это сдавать заказчику.
✅2.Не знаю свежую статистику % успешных проектов, но от 80 до 90% айти проектов, продуктов провальны, по причине того, что мы делаем, то что никому было не нужно, никто это не просил, или не просил в таком виде.
✅3.Рост количества переделок, "не попадания в цель", становится критичным или дорогим. Тут зависит от сферы, часто B2C сервисы, могут позволить себе клепать быстро, чтобы захватить рынок или протестировать гипотезу. В B2G, B2C, в сложном Enterprise у нас нет права совершать множество ошибок и смотреть конечный результат, а потом разводить руками - "не шмогла, не шмогла..."
✅4.Так хочется сразу перейти к решению. Это в том числе наши любимые когнитивные искажения, нашему мозгу проще перейти в ту область, где мы себя чувствуем увереннее и понимаем о чем идёт речь. Подмена понятий, тоже сюда. Упростить и сразу говорить о решение. Эмоций больше, приятнее и есть ощущение действия, результата.
И вот потратив время на исследование проблемы, аналитик приступает к описанию решения на языке требований. И тут это отдельное искусство описать так, чтобы у команды была возможность выбрать технологии, оптимальные, эффектные реализации. Не прибивая всё гвоздями.
И будем реалистами, работа аналитика правда сложная, наши айти проекты правда сложные, и наши заказчики люди с множеством мыслей, эмоций, своим мнением, опытом, и к ним нужно искать подход, а работа с людьми это тяжело.
Как бы не хотел аналитик откреститься от заказчика, потому что, часто общение с заказчиком это сложно, ресурсоемко, и нужно быть психологом, коучем, чтобы найти контакт. Но горькая правда в том, что приходится прокачивать себя в переговорах, коммуникации и управление ожиданиями заказчика, чтобы исследовать проблему и только потом переходить к решению, которое должно помогать заказчику получать ожидаемый эффект.
Вот такие сегодня местами сложные мысли)
#мысливслух #сбортребований #исследование #проектирование #правдажизни
Как запрыгнуть в проект на полном ходу и выжить?
Часть 1. 🚅
Условие - аналитика бросили в разработку, когда уже всё запущено и работает.
То есть поезд уже запущен и с большой скоростью едет по рельсам. А тебя в него закинули и ты должен понять куда, в вагон ресторан, в пассажирский вагон или в кабину машиниста. При этом дали задачу "сварить кофе". И вот надо понять, ты готовишь как бариста (если умеешь) в ресторане, или просто разводишь в кипятке или надо заказать приготовление кофе к вагону, для кого-то.
Что делать?
Пойти уволиться))
Хочется пойти по классике онбординга, который никто не отменял. Поэтому в самом начале, я бы пошла собирать основную информацию и освоение я бы вела в следующих направлениях:
✅1.Устройство компании, в чем цель бизнеса, место айти команды в нём и аналитика соответственно. Ответ на вопрос где я?
✅2.Устройство команды, кто Тим Лид, какая была история создания. Как ведётся управление, какие методологии (если они вообще были). И как в этих процессах участвует аналитик. Ответ на вопрос кто я тут?
✅3.Карта stakholders, кто за что отвечает, кто мне ставит задачи, кто будет их принимать (100500 руководителей не самый лучший вариант). Мне же хочется закрыть задачу и закрыть сносно и успешно.
✅4.Управление проектами, продуктами, цели, сроки, бюджеты, ресурсы, риски. Как это всё влияет на мою задачу?
Основы, короче говоря, осмотрелась вокруг и поняла, в каком я вагоне отказалась, "горящем на полном ходу, или в вагоне ресторане", иначе сложно понять свою задачу и критерии того, как её делать, кому сдавать, закрывать.
Это первый шаг, а вы с чего начинаете работу над новым проектом?🤔
#запрыгнутьвпроект #онбординг #первыйшаг #правдажизни #мойопыт
Часть 1. 🚅
Условие - аналитика бросили в разработку, когда уже всё запущено и работает.
То есть поезд уже запущен и с большой скоростью едет по рельсам. А тебя в него закинули и ты должен понять куда, в вагон ресторан, в пассажирский вагон или в кабину машиниста. При этом дали задачу "сварить кофе". И вот надо понять, ты готовишь как бариста (если умеешь) в ресторане, или просто разводишь в кипятке или надо заказать приготовление кофе к вагону, для кого-то.
Что делать?
Хочется пойти по классике онбординга, который никто не отменял. Поэтому в самом начале, я бы пошла собирать основную информацию и освоение я бы вела в следующих направлениях:
✅1.Устройство компании, в чем цель бизнеса, место айти команды в нём и аналитика соответственно. Ответ на вопрос где я?
✅2.Устройство команды, кто Тим Лид, какая была история создания. Как ведётся управление, какие методологии (если они вообще были). И как в этих процессах участвует аналитик. Ответ на вопрос кто я тут?
✅3.Карта stakholders, кто за что отвечает, кто мне ставит задачи, кто будет их принимать (100500 руководителей не самый лучший вариант). Мне же хочется закрыть задачу и закрыть сносно и успешно.
✅4.Управление проектами, продуктами, цели, сроки, бюджеты, ресурсы, риски. Как это всё влияет на мою задачу?
Основы, короче говоря, осмотрелась вокруг и поняла, в каком я вагоне отказалась, "горящем на полном ходу, или в вагоне ресторане", иначе сложно понять свою задачу и критерии того, как её делать, кому сдавать, закрывать.
Это первый шаг, а вы с чего начинаете работу над новым проектом?🤔
#запрыгнутьвпроект #онбординг #первыйшаг #правдажизни #мойопыт
Please open Telegram to view this post
VIEW IN TELEGRAM
Перепрыгнуть ступени или естественное развитие?
Немного соскучилась по бизнес литературе и вот мне в руки попала книга "The filter", про нельзяграм. Пока сложно делать выводы или транслировать вам книгу. Но есть одна мысль, которую я уже высказывала и она снова мне нравится, и снова есть её доказательство.
Что всё развивается естественно, из ничего невозможно построить результат. Также же и с нельзяграм, его создатели до него доросли и создали новое, с новым феноменом. Любовь к фотографии и её изучение помогло и дало кирпичик в основу, одному из основателей. Образование, связи в Стэнфорде, отказ от предложения работать в Google. Череда событий и работа годами приносит результат.
Ещё прикиньте вы знакомы с основателем Google, он вас, как выпускника и студента. Стэнфорда хантит в Google, а вы отказываетесь. Он приходит в кофейню, где вы бариста, и округляет глаза)))) Ради чего был отказ? Ради кофе??)
Все современные тренды говорят о некой магии. И часто можно услышать, что вот вжух, и создан REST API, вжух и Facebook, вжух и Google, и т.д. Но когда изучаешь историю, понимаешь, что всё создаётся не просто так, и не с полпинка, легко и с магией. А работа годами. Опыт сложный с потом, кровью, личными качествами. Хотя конечно есть в книгах такой американ флёр, красивой жизни, типа у него не было ничего, но вот он учился, учился, работал везде, был официантом, много себя прокачивал и вот, вот, вот получился результат! Бинго!
Это даже лучше, чем отпустить шарик в небо и ждать, что оно с неба упадёт. Мы же заплатили деньги, а что теперь ещё и что-то делать нужно?
Конечно можно выжимать из себя многое, особенно когда ты молод, амбициозен и здоров. Но за всё приходит плата здоровьем, временем, деньгами, эмоциями, отношениями. У каждого своё.
Можно напрячься, мы все это делаем, но нужно потом закладывать время и ресурс на откат, восстановление.
Как сказал один тим лид, что можно вкалывать на стартапе, если у вас есть возможность потом взять перерыв в полгода, год.
А последние годы научили лавировать "здесь и сейчас". Что у меня есть и что мне по силам. И в итоге ускорить те или иные процессы все пытаются, но мы не боги и естественные процессы сильнее, и они берут верх.
#естестевенноеразвитие #books #мояполка #мысливслух #правдажизни #мирвокруг #моемнение
Немного соскучилась по бизнес литературе и вот мне в руки попала книга "The filter", про нельзяграм. Пока сложно делать выводы или транслировать вам книгу. Но есть одна мысль, которую я уже высказывала и она снова мне нравится, и снова есть её доказательство.
Что всё развивается естественно, из ничего невозможно построить результат. Также же и с нельзяграм, его создатели до него доросли и создали новое, с новым феноменом. Любовь к фотографии и её изучение помогло и дало кирпичик в основу, одному из основателей. Образование, связи в Стэнфорде, отказ от предложения работать в Google. Череда событий и работа годами приносит результат.
Ещё прикиньте вы знакомы с основателем Google, он вас, как выпускника и студента. Стэнфорда хантит в Google, а вы отказываетесь. Он приходит в кофейню, где вы бариста, и округляет глаза)))) Ради чего был отказ? Ради кофе??)
Все современные тренды говорят о некой магии. И часто можно услышать, что вот вжух, и создан REST API, вжух и Facebook, вжух и Google, и т.д. Но когда изучаешь историю, понимаешь, что всё создаётся не просто так, и не с полпинка, легко и с магией. А работа годами. Опыт сложный с потом, кровью, личными качествами. Хотя конечно есть в книгах такой американ флёр, красивой жизни, типа у него не было ничего, но вот он учился, учился, работал везде, был официантом, много себя прокачивал и вот, вот, вот получился результат! Бинго!
Это даже лучше, чем отпустить шарик в небо и ждать, что оно с неба упадёт. Мы же заплатили деньги, а что теперь ещё и что-то делать нужно?
Конечно можно выжимать из себя многое, особенно когда ты молод, амбициозен и здоров. Но за всё приходит плата здоровьем, временем, деньгами, эмоциями, отношениями. У каждого своё.
Можно напрячься, мы все это делаем, но нужно потом закладывать время и ресурс на откат, восстановление.
Как сказал один тим лид, что можно вкалывать на стартапе, если у вас есть возможность потом взять перерыв в полгода, год.
А последние годы научили лавировать "здесь и сейчас". Что у меня есть и что мне по силам. И в итоге ускорить те или иные процессы все пытаются, но мы не боги и естественные процессы сильнее, и они берут верх.
#естестевенноеразвитие #books #мояполка #мысливслух #правдажизни #мирвокруг #моемнение
У меня хорошая новость, я приеду в Новосибирск на CodeFest, который состоится уже в эти выходные 😍
К сожалению в этот раз без доклада, но хочу поучаствовать в квартирнике, где мы будем обсуждать плюсы и минусы совмещения ролей аналитика и руководителя проекта.
На эту тему Евгений Галактионов на днях сделал свой 👉 пост и поднял информацию вебинара с раскрытием темы.
Кто из Новосибирска, пишите, можем пересечься, пообщаться и кучковаться аналитиками на конференции))
Уже жду с нетерпением 😎
P. S. Буду транслировать тут, тезисы и выводы, из того что удастся посетить)
#CodeFest #конференция
К сожалению в этот раз без доклада, но хочу поучаствовать в квартирнике, где мы будем обсуждать плюсы и минусы совмещения ролей аналитика и руководителя проекта.
На эту тему Евгений Галактионов на днях сделал свой 👉 пост и поднял информацию вебинара с раскрытием темы.
Кто из Новосибирска, пишите, можем пересечься, пообщаться и кучковаться аналитиками на конференции))
Уже жду с нетерпением 😎
P. S. Буду транслировать тут, тезисы и выводы, из того что удастся посетить)
#CodeFest #конференция
Меня тут спросили, а будет ли, что-то в Москве очно из мероприятий.
Туда, куда я собираюсь, если мне хватит на всё сил, это митап от компании ITFB.
Пройдёт 30 мая, четверг, очно, но также можно смотреть в онлайн режиме (количество оффлайн мест ограничено!)
Ссылка с описанием и регистрацией
👉 https://itfbgroup.ru/meetup_analytics
Туда, куда я собираюсь, если мне хватит на всё сил, это митап от компании ITFB.
Пройдёт 30 мая, четверг, очно, но также можно смотреть в онлайн режиме (количество оффлайн мест ограничено!)
Ссылка с описанием и регистрацией
👉 https://itfbgroup.ru/meetup_analytics
itfbgroup.ru
ITFB Meetup для бизнес и системных аналитиков
Будем говорить про полезные инструменты, открытия, поучительные истории с проектов, и в целом, делиться опытом друг с другом!
CodeFest 14 стартовал! Ура! 🥳
Где буду я?
Буду на двух квартирниках сегодня и завтра.
👉Сегодня 25.05.2024 - встречаемся 14:00 - 14:40
Тема:
Руководитель и специалист. Проблемы совмещения.
👉Завтра 26.05.2024
встречаемся 16:00 - 16:40
Тема:
Найти за 60 минут: как нанять хорошего аналитика.
Где буду я?
Буду на двух квартирниках сегодня и завтра.
👉Сегодня 25.05.2024 - встречаемся 14:00 - 14:40
Тема:
Руководитель и специалист. Проблемы совмещения.
👉Завтра 26.05.2024
встречаемся 16:00 - 16:40
Тема:
Найти за 60 минут: как нанять хорошего аналитика.
Кратко о докладе Константина Волкова.
Мой пересказ)
Переговоры способом - Конструктивной конфроктации.
Часто мы приходим на переговоры с решением. Сложно разнести проблему и решение. Переговоры могут занимать около часа. Оказывается можно уложиться быстрее - "семисекундная точка согласия". И она точно есть. Представьте, что можно достичь согласия за 7 секунд!
Это очень короткий срок. Как? С помощью мысли, которая должна быть высказана предельно ясно, ничего лишнего, вырезать лишние слова, каждое слово должно быть подобрано идеально.
Подготовка нужна!
Люди практически никогда не готовятся к переговорам. Вы знаете, что предстоит тяжёлый разговор, но вы не готовитесь. Например, самый сложный кейс у меня занял 8 часов, 3 часа подготовка с консультантом, и 5 часов изусение нюансов. Это был разговор "последний шанс", перед увольнением человека. Мы сохранили хорошие отношения с этим человеком и хорошие отношения внутри компании. Уважение основа!
Уважительный разговор одинаково зеркалит на обоих собеседников.
Нужно готовиться обоим сторонам. Если конечно другая сторона не готова, 50% успеха у вас есть за счёт вашей подготовки.
Что делать?
Определяем - Ваши цели и проблемы.
Узнаем - И цели и проблемы собеседника.
Нужно искать пересечение. И мы обычно не интересуемся целями собеседника.
Если спрашивать "чего же ты хочешь на самом деле?" Чаще всего мы услышим искренний ответ.
Когда вы не попадаете в цель собеседника, он вас даже не слышит, как в сказке три девицы под окном... Мы все помним про "родить богатыря", про предложения двух других не помним. Если мы скажите, то что нужно, ваш собеседник скажет сразу да!
Все разговоры имеют цель. Даже бесполезные митинги. Если вы начнёте говорить о цели, то ваши разговоры станут более конструктивными.
Чего хотел кресный отец в фильме?
Дружбу. Для него важны связи и они его волнуют. Кресный отец принимает дружбу. Попадание в метку цели - открывает для вас пространство новых решений, которые изначально были недоступны.
Программисты - проблемный народ. Даёшь им деньги, условия, они всё равно выгорают. Что делать?)
А если спросить у программиста?
Ответ - дайте спокойно поработать, не мешайте!
Все инженеры мечтают делать успешные проекты. Отсюда - тренд - успешный успех.
Достичь успеха очень просто - обмани, укради, но успешный успех недолговечен.
Адизес нас говорит - нужно добиваться устойчего успеха, который ты каждый день можешь воспроизводить. Его можно добиться комплементарной командой.
Самая распространённая команда - семья, муж и жена. Залог успешной командной работы это участие каждого участника, комплементарность.
Самое сложное - договориться.
Ещё и сложным людям о сложном, сложно договориться.
Залог успеха такой команды - это взаимное уважение.
Иерархия потребностей специалистов. Самый верх это вовлеченность, где-то в середине личное развитие. И всё построено на личном уважение друг к другу. Какое уважение в компаниях, когда руководители говорят вот выйдет новый chatgpt и мы просто всех уволим!
Нужно создавать взаимное уважение с безопасной средой - это залог обучения и развития.
Тренируемся в общение!)
#CodeFest14 #уважение #доклад
Мой пересказ)
Переговоры способом - Конструктивной конфроктации.
Часто мы приходим на переговоры с решением. Сложно разнести проблему и решение. Переговоры могут занимать около часа. Оказывается можно уложиться быстрее - "семисекундная точка согласия". И она точно есть. Представьте, что можно достичь согласия за 7 секунд!
Это очень короткий срок. Как? С помощью мысли, которая должна быть высказана предельно ясно, ничего лишнего, вырезать лишние слова, каждое слово должно быть подобрано идеально.
Подготовка нужна!
Люди практически никогда не готовятся к переговорам. Вы знаете, что предстоит тяжёлый разговор, но вы не готовитесь. Например, самый сложный кейс у меня занял 8 часов, 3 часа подготовка с консультантом, и 5 часов изусение нюансов. Это был разговор "последний шанс", перед увольнением человека. Мы сохранили хорошие отношения с этим человеком и хорошие отношения внутри компании. Уважение основа!
Уважительный разговор одинаково зеркалит на обоих собеседников.
Нужно готовиться обоим сторонам. Если конечно другая сторона не готова, 50% успеха у вас есть за счёт вашей подготовки.
Что делать?
Определяем - Ваши цели и проблемы.
Узнаем - И цели и проблемы собеседника.
Нужно искать пересечение. И мы обычно не интересуемся целями собеседника.
Если спрашивать "чего же ты хочешь на самом деле?" Чаще всего мы услышим искренний ответ.
Когда вы не попадаете в цель собеседника, он вас даже не слышит, как в сказке три девицы под окном... Мы все помним про "родить богатыря", про предложения двух других не помним. Если мы скажите, то что нужно, ваш собеседник скажет сразу да!
Все разговоры имеют цель. Даже бесполезные митинги. Если вы начнёте говорить о цели, то ваши разговоры станут более конструктивными.
Чего хотел кресный отец в фильме?
Дружбу. Для него важны связи и они его волнуют. Кресный отец принимает дружбу. Попадание в метку цели - открывает для вас пространство новых решений, которые изначально были недоступны.
Программисты - проблемный народ. Даёшь им деньги, условия, они всё равно выгорают. Что делать?)
А если спросить у программиста?
Ответ - дайте спокойно поработать, не мешайте!
Все инженеры мечтают делать успешные проекты. Отсюда - тренд - успешный успех.
Достичь успеха очень просто - обмани, укради, но успешный успех недолговечен.
Адизес нас говорит - нужно добиваться устойчего успеха, который ты каждый день можешь воспроизводить. Его можно добиться комплементарной командой.
Самая распространённая команда - семья, муж и жена. Залог успешной командной работы это участие каждого участника, комплементарность.
Самое сложное - договориться.
Ещё и сложным людям о сложном, сложно договориться.
Залог успеха такой команды - это взаимное уважение.
Иерархия потребностей специалистов. Самый верх это вовлеченность, где-то в середине личное развитие. И всё построено на личном уважение друг к другу. Какое уважение в компаниях, когда руководители говорят вот выйдет новый chatgpt и мы просто всех уволим!
Нужно создавать взаимное уважение с безопасной средой - это залог обучения и развития.
Тренируемся в общение!)
#CodeFest14 #уважение #доклад
Григорий Петров. Сложность, убивающая микросервисы. Evron.
Приходят go и другие модные разработчики и говорят давайте микросервисы!
Будет проще! нет!
Откуда микросервисы пошли? Им много лет, аж с 1990-х. Тогда были сервера вертикально масштабируемые. Распреденные системы, сложные, я с ними работал и мне они не понравились)
Осторожная критика микросервисов сейчас уже пошла. Что видим?
Амазон, вотсап... Большие компании, с большими ресурсами.
Аудит стартапов нам говорит, чем проще, тем лучше. Стоп, микросервисы же это просто?
Что может пойти не так?
Я хочу быстро обучать программистов. Обучал 3 года, а работали они 1,5 года. Что-то не так...
Как наш мозг может осознавать код и что его делает сложным?
Современные нейрофизиологи не знают, что такое сознание, но предполагают, что это память. Мы активируем 1000 смыслов. Но смыслы не активированы на вечно, если нет связей, то смысл деактивирован. Быстрая память - то что сейчас активно 7 плюс минус 2.
Кошелёк Миллера - хотим осознать новые штуки. Вот Вася, он представился, и вот я направил на него внимание, и вот Коля и я на его переключил своё внимание и уже фокус уходит с Васи. И вот туда сюда переключаю свой кэш.
Если смотреть последние исследования, испытания, то на самом деле человек удерживает 5-4 пунктов в своём кэше памяти.
Мы работаем в долговременной памяти с кодом. Мы осознаем не текст, а смыслы, когда читаем код. И из фреймворка берём смыслы, из опыта использования кода, библиотек, из общих идиом программирования, из имён и идентификаторов.
Синтаксис языка программирования это очень маленький кусок знаний. Все мы помним книги - "Освоить программирование за 20 за 4 часа", такое себе на самом деле.
Наше сознание похоже на кусок графа. С одной стороны активирует смыслы, достраивается, а с другой стороны разрушается. И мы достраиваем в реалтайме по тем смыслам, что уже знаем.
Черновая структура части проекта, который осознаем. Что мы пилим сейчас это дни и оно переходит в долговременную память. Если месяца, то оседает в памяти, и годы старожилы проекта это несущие конструкции огромные сложные детали, которые дают возможность осознать код. И нам нужны все! И в нашем мозгу есть инструмент, чтобы осознать проект.
Мозг одна большая обобщалка. Художник может сделать шаг назад и посмотреть картину целиком, а программист не может так сделать.
А на сколько хорошо, мы можем махаться в микросервисах со сложностями в проекте?
Для монолитов есть фреймворки, и опыт измеряется годами, и для которых есть смыслы, и мы можем строить большие конструкции в мозгу.
Для микросервисов нет и мы вынуждены делать свои велосипеды, чтобы ориентироваться в проекте. Нужно знать карту микросервисов, команды, которая их поддерживает. Нам приходится общаться с другими командами, а фреймворков нет.
Осознание кода ограничено деталями легко, которые сформировались годами. У нас уже должно быть в голове смыслы, чтобы работать с большим проектом. Открыл монолит и всё понятно.
А у микросервисов нет. Есть кубирнейтс, ну это не то. Это управление операционной системой, инфраструктурой описания, но не кода и описание кода для реализации бизнес задачи. Внутренняя дев платформа в итоге появляется в каждой компании.
Нам нужно минимум 10 лет, чтобы организовать самую большую - длительную память. Реальный пример. Пациенту удалили гипокам и человек не смог формировать долговременную память. Доктор представился, пациент отвлёкся и сразу кэш очистилаюся. И доктор заново представлялся. У пациента отрезало память на 10 лет в прошлое, и всё больше больше тумана и воспоминания не сформировались. И вдруг поняли, что долговременная память формируется 10 лет.
Нам нужна годы для dev платформ! Такая цена чтобы у разработчиков сформировать детали лего памяти.
Известные фреймворки сформировали общие детали лего. И новые разработчики осознавали код быстро. А сейчас у всех дев платформы разные и нужно время чтобы их освоить и вот нужны ресурсы для постоянного онбординга разработчиков.
👇
Приходят go и другие модные разработчики и говорят давайте микросервисы!
Будет проще! нет!
Откуда микросервисы пошли? Им много лет, аж с 1990-х. Тогда были сервера вертикально масштабируемые. Распреденные системы, сложные, я с ними работал и мне они не понравились)
Осторожная критика микросервисов сейчас уже пошла. Что видим?
Амазон, вотсап... Большие компании, с большими ресурсами.
Аудит стартапов нам говорит, чем проще, тем лучше. Стоп, микросервисы же это просто?
Что может пойти не так?
Я хочу быстро обучать программистов. Обучал 3 года, а работали они 1,5 года. Что-то не так...
Как наш мозг может осознавать код и что его делает сложным?
Современные нейрофизиологи не знают, что такое сознание, но предполагают, что это память. Мы активируем 1000 смыслов. Но смыслы не активированы на вечно, если нет связей, то смысл деактивирован. Быстрая память - то что сейчас активно 7 плюс минус 2.
Кошелёк Миллера - хотим осознать новые штуки. Вот Вася, он представился, и вот я направил на него внимание, и вот Коля и я на его переключил своё внимание и уже фокус уходит с Васи. И вот туда сюда переключаю свой кэш.
Если смотреть последние исследования, испытания, то на самом деле человек удерживает 5-4 пунктов в своём кэше памяти.
Мы работаем в долговременной памяти с кодом. Мы осознаем не текст, а смыслы, когда читаем код. И из фреймворка берём смыслы, из опыта использования кода, библиотек, из общих идиом программирования, из имён и идентификаторов.
Синтаксис языка программирования это очень маленький кусок знаний. Все мы помним книги - "Освоить программирование за 20 за 4 часа", такое себе на самом деле.
Наше сознание похоже на кусок графа. С одной стороны активирует смыслы, достраивается, а с другой стороны разрушается. И мы достраиваем в реалтайме по тем смыслам, что уже знаем.
Черновая структура части проекта, который осознаем. Что мы пилим сейчас это дни и оно переходит в долговременную память. Если месяца, то оседает в памяти, и годы старожилы проекта это несущие конструкции огромные сложные детали, которые дают возможность осознать код. И нам нужны все! И в нашем мозгу есть инструмент, чтобы осознать проект.
Мозг одна большая обобщалка. Художник может сделать шаг назад и посмотреть картину целиком, а программист не может так сделать.
А на сколько хорошо, мы можем махаться в микросервисах со сложностями в проекте?
Для монолитов есть фреймворки, и опыт измеряется годами, и для которых есть смыслы, и мы можем строить большие конструкции в мозгу.
Для микросервисов нет и мы вынуждены делать свои велосипеды, чтобы ориентироваться в проекте. Нужно знать карту микросервисов, команды, которая их поддерживает. Нам приходится общаться с другими командами, а фреймворков нет.
Осознание кода ограничено деталями легко, которые сформировались годами. У нас уже должно быть в голове смыслы, чтобы работать с большим проектом. Открыл монолит и всё понятно.
А у микросервисов нет. Есть кубирнейтс, ну это не то. Это управление операционной системой, инфраструктурой описания, но не кода и описание кода для реализации бизнес задачи. Внутренняя дев платформа в итоге появляется в каждой компании.
Нам нужно минимум 10 лет, чтобы организовать самую большую - длительную память. Реальный пример. Пациенту удалили гипокам и человек не смог формировать долговременную память. Доктор представился, пациент отвлёкся и сразу кэш очистилаюся. И доктор заново представлялся. У пациента отрезало память на 10 лет в прошлое, и всё больше больше тумана и воспоминания не сформировались. И вдруг поняли, что долговременная память формируется 10 лет.
Нам нужна годы для dev платформ! Такая цена чтобы у разработчиков сформировать детали лего памяти.
Известные фреймворки сформировали общие детали лего. И новые разработчики осознавали код быстро. А сейчас у всех дев платформы разные и нужно время чтобы их освоить и вот нужны ресурсы для постоянного онбординга разработчиков.
👇
Текущая культура микросервисов провоцирует зоопарк технологий. Каждый участник команды хочет применить свою технологию, и мы говорим, не проблема, давай. И тогда приходится поддерживать весь процесс - написания, поддержки и итог, микросервис перестаёт быть простым.
Распределенная систем это микросервис, сделать хороший интеграционный тест невозможно, для таких систем. Мы пишем как бы это протестировать, но это не бесплатно.
Ещё мы думаем, что программист инженер с высшим образованием, он же умный и он любой трюк может поддержать. Но это не так, мы можем определять только те смыслы, которые годами сформировались. А вот у нас новое, а человек годами с монолитом работал. И для нового ему нужны месяцы - чтобы разобраться, и годы чтобы начать работать.
Микросервисы не прощают плохие архитектурные решения, хаки, растёт тех долг. Не можем копит тех долг, может возникнуть ситуация, когда через пару недель не будет работать наш микросервис.
Микросервисы - это круто! Нам дали деньги и залили на миллионы рпс, проекты ценой огромных инвестиций в том числе в обучение людей. Как мы с этим кодом будем работать - это проблема. В огромных компаниях оно хорошо работает. И вот нам говорят, давайте сделаем микросервисы, но распил монолита не будет проще. Микросервисы не могут быть заменой монолита, ибо добавляют новый уровень сложности. Например, Вася говно кодил в монолит, и потом всё встало, а в микросервисах можно их изолировать. Микросервисы вот оно круто. Да, но нет.
Проблема сложности ПО. Когда выбираем архитектору, языки, тулинги, это все не бесплатно. Наш мозг это не бесплатно и нужно время чтобы научиться думать о больших штуках.
В монолите есть архитектурные границы. Культура в микросервисах, та что есть сейчас не даёт нам простоту.
Код стоит писать так, чтобы он рассказывал историю без вас, как суфлера. Если вы думаете нужны ли вам стандарты создания кода - нужны, делайте!
Нужен большой опыт тим лидов и архитекторов.
Когнитивная сложность монолита и микросервисов разная для сеньора и джуна.
#CodeFest14 #микросервисы #доклад #ГригорийПетров
Распределенная систем это микросервис, сделать хороший интеграционный тест невозможно, для таких систем. Мы пишем как бы это протестировать, но это не бесплатно.
Ещё мы думаем, что программист инженер с высшим образованием, он же умный и он любой трюк может поддержать. Но это не так, мы можем определять только те смыслы, которые годами сформировались. А вот у нас новое, а человек годами с монолитом работал. И для нового ему нужны месяцы - чтобы разобраться, и годы чтобы начать работать.
Микросервисы не прощают плохие архитектурные решения, хаки, растёт тех долг. Не можем копит тех долг, может возникнуть ситуация, когда через пару недель не будет работать наш микросервис.
Микросервисы - это круто! Нам дали деньги и залили на миллионы рпс, проекты ценой огромных инвестиций в том числе в обучение людей. Как мы с этим кодом будем работать - это проблема. В огромных компаниях оно хорошо работает. И вот нам говорят, давайте сделаем микросервисы, но распил монолита не будет проще. Микросервисы не могут быть заменой монолита, ибо добавляют новый уровень сложности. Например, Вася говно кодил в монолит, и потом всё встало, а в микросервисах можно их изолировать. Микросервисы вот оно круто. Да, но нет.
Проблема сложности ПО. Когда выбираем архитектору, языки, тулинги, это все не бесплатно. Наш мозг это не бесплатно и нужно время чтобы научиться думать о больших штуках.
В монолите есть архитектурные границы. Культура в микросервисах, та что есть сейчас не даёт нам простоту.
Код стоит писать так, чтобы он рассказывал историю без вас, как суфлера. Если вы думаете нужны ли вам стандарты создания кода - нужны, делайте!
Нужен большой опыт тим лидов и архитекторов.
Когнитивная сложность монолита и микросервисов разная для сеньора и джуна.
#CodeFest14 #микросервисы #доклад #ГригорийПетров
Мнообразие ТимЛидов.
Евгений Антонов.
Инфраструктура Яндекса.
Шизо вакансии - на 80% писать код и на 80% быть тим лидом, на 80% (?..)
Где-то продакт, где-то аналитик, где-то тестировщик, где-то релиз инженер...
И всё это играющий тренер. Всё это приводит к овертаймам. Код пописал, а вечером на выходных заняться процессами. Это безумие и выгорание, ты искреннее стараешься, но всё хуже и хуже справляешься.
Демотивация ответственного за мотивацию.
Что делать?
Уменьшить скоуп
Или уменьшить качество.
Задать себе вопрос, что нравится делать, куда готовы расти и развиваться?
Адизес описал график жизни компании.
Вы приходите в компанию на опреденном этапе жизни этой компании.
Предлагаю - 4 стадии, которые могут случиться:
✅Сбор команды
✅Поддержка текущей команды
✅Развитие команды
✅Кризис
4 вида тим лидов :
Создающий бизнес, чтобы он заработал.
Из оффлайн, например, переход в онлайн и ничего нет, надо построить с нуля.
Кажется, если ты создаёшь с нуля нужно много уметь. Тут предлагаю срезать качество. Например, Хотим бегать, можно и не покупать спец вещи, берём что есть и побежали. Для новых команд нужно, как можно быстрее создаться. Нужны навыки найма и знания, как какие процессы найма работают. Делать простые супер капитанские вещи.
Люди - 4 стадии формирования команды. Притирка в команде. Сделать так, чтобы команда не развалилась - задача тим лида.
Что делать с архитектурой?
Набирая команду, берете норм экспертов. Уметь привлекать внешний консалтинг. Я знаю того мужика, который знает.
Поддерживающий.
Команда уже есть, надо приходить и немного пинать. Тут проще, команда есть. Достаётся чаще всего, то что уже работает или можно свалить на предыдущего тим лида, если что-то не так.
Нужна дисциплина. Кто-то думал, что будет тим Лидом, но он не стал. Или кто-то хочет что-то пропихнуть.
Сознательность.
Зашли, посмотрели, опросили, сознательное внедрение, а не переламывание через хребет. Учится делегировать, чтобы команда работала без вас, вклад в долгосрочность команды.
Администратор - склонность к административности.
Если у вас каждая снежинка летает, там где она хочет)
Простая точка входа в тим лидерство.
Развивающий
Кажется нужен широкий кругозор при быстром росте команды. Либо срезать скоуп, либо срезать качество. Качество на больших масштабах нельзя срезать.
Всех нанял, выгорел и уволился.
Знание релевантной области необходимо.
Продвинутый уровень рекрутинга и делигирования. Стандарт междукомандного взаимодействия.
Долгосрочное планирование.
Антикризисный
Все поругались, сложные процессы. Нужны быстрые и жёсткие решения. Невозможно решить проблему поцелуями во все места, по любому кто-то будет недоволен.
Нужно уметь микроменеджерить (тут можно!)
Тушить сейчас нужно уметь.
Чёрный пояс по увольнению.
Управлять рисками и быть к ним готовым, они 100% случаться и вас затронут. Не будет лёгкого безболезненного труда.
Лидерские качества (сериал Тед Лассо).
Коммуникация - не только поговорить, но и под ковром разбираться в корпоративной политике. Хотеть и уметь разбираться в политике.
Будьте хорошим тим лидом, а плохим не будьте)
#CodeFest14 #типыТимЛидов #доклад
Евгений Антонов.
Инфраструктура Яндекса.
Шизо вакансии - на 80% писать код и на 80% быть тим лидом, на 80% (?..)
Где-то продакт, где-то аналитик, где-то тестировщик, где-то релиз инженер...
И всё это играющий тренер. Всё это приводит к овертаймам. Код пописал, а вечером на выходных заняться процессами. Это безумие и выгорание, ты искреннее стараешься, но всё хуже и хуже справляешься.
Демотивация ответственного за мотивацию.
Что делать?
Уменьшить скоуп
Или уменьшить качество.
Задать себе вопрос, что нравится делать, куда готовы расти и развиваться?
Адизес описал график жизни компании.
Вы приходите в компанию на опреденном этапе жизни этой компании.
Предлагаю - 4 стадии, которые могут случиться:
✅Сбор команды
✅Поддержка текущей команды
✅Развитие команды
✅Кризис
4 вида тим лидов :
Создающий бизнес, чтобы он заработал.
Из оффлайн, например, переход в онлайн и ничего нет, надо построить с нуля.
Кажется, если ты создаёшь с нуля нужно много уметь. Тут предлагаю срезать качество. Например, Хотим бегать, можно и не покупать спец вещи, берём что есть и побежали. Для новых команд нужно, как можно быстрее создаться. Нужны навыки найма и знания, как какие процессы найма работают. Делать простые супер капитанские вещи.
Люди - 4 стадии формирования команды. Притирка в команде. Сделать так, чтобы команда не развалилась - задача тим лида.
Что делать с архитектурой?
Набирая команду, берете норм экспертов. Уметь привлекать внешний консалтинг. Я знаю того мужика, который знает.
Поддерживающий.
Команда уже есть, надо приходить и немного пинать. Тут проще, команда есть. Достаётся чаще всего, то что уже работает или можно свалить на предыдущего тим лида, если что-то не так.
Нужна дисциплина. Кто-то думал, что будет тим Лидом, но он не стал. Или кто-то хочет что-то пропихнуть.
Сознательность.
Зашли, посмотрели, опросили, сознательное внедрение, а не переламывание через хребет. Учится делегировать, чтобы команда работала без вас, вклад в долгосрочность команды.
Администратор - склонность к административности.
Если у вас каждая снежинка летает, там где она хочет)
Простая точка входа в тим лидерство.
Развивающий
Кажется нужен широкий кругозор при быстром росте команды. Либо срезать скоуп, либо срезать качество. Качество на больших масштабах нельзя срезать.
Всех нанял, выгорел и уволился.
Знание релевантной области необходимо.
Продвинутый уровень рекрутинга и делигирования. Стандарт междукомандного взаимодействия.
Долгосрочное планирование.
Антикризисный
Все поругались, сложные процессы. Нужны быстрые и жёсткие решения. Невозможно решить проблему поцелуями во все места, по любому кто-то будет недоволен.
Нужно уметь микроменеджерить (тут можно!)
Тушить сейчас нужно уметь.
Чёрный пояс по увольнению.
Управлять рисками и быть к ним готовым, они 100% случаться и вас затронут. Не будет лёгкого безболезненного труда.
Лидерские качества (сериал Тед Лассо).
Коммуникация - не только поговорить, но и под ковром разбираться в корпоративной политике. Хотеть и уметь разбираться в политике.
Будьте хорошим тим лидом, а плохим не будьте)
#CodeFest14 #типыТимЛидов #доклад
Forwarded from Уставший техдир
Конференции и стенды компаний
За последние несколько лет стенды компаний из коммуникационной платформы между компанией и комьюнити превратились в лутовые. Ты приходишь к ним, а там конкурсы, тесты, викторины, и везде какие-то призы. От простых механик вида оставь контакты получи кружку, до розыгрышей айфонов с барабаном из спорт лотто.
Вроде почему нет, компании ок, а посетителем фан и быстрый дофамин (а иногда и ценные призы, че уж греха таить, кто откажется от айфона?). Но все это уводит фокус куда-то не туда. Вместо пообщаться с компанией и узнать о ней больше ты лутаешь носки. И в моем представлении это проблема. Во-первых этот лут потом пылиться дома или, в лучшем случае, украшает офис. Во-вторых это достаточно весомый объем бюджета, который уходит в никуда
И тут Сбер на CodeFest сделал интересный эксперимент, вместо дорогого-красивого стенда и мягких игрушек сделал голый белый стенд. А вместо призов перенаправил бюджет на благотворительность! Каждый человек, который коммуницирует на стенде увеличивает размер фонда. А весь фонд по итогам конференции будет потрачен на технику в классе информатики для Новосибирского лицея №28
При этом, это не хуже работает на технобренд компании, но и приносит пользу обществу. Ну не красота-ли? Надеюсь, что и другие компании последуют этому примеру, а то весь этот мерч уже как не в коня корм.
https://conference-nsk.ru/
Что думаете, как еще можно в лучшую сторону изменить привычную коммуникацию компаний на конференциях?
За последние несколько лет стенды компаний из коммуникационной платформы между компанией и комьюнити превратились в лутовые. Ты приходишь к ним, а там конкурсы, тесты, викторины, и везде какие-то призы. От простых механик вида оставь контакты получи кружку, до розыгрышей айфонов с барабаном из спорт лотто.
Вроде почему нет, компании ок, а посетителем фан и быстрый дофамин (а иногда и ценные призы, че уж греха таить, кто откажется от айфона?). Но все это уводит фокус куда-то не туда. Вместо пообщаться с компанией и узнать о ней больше ты лутаешь носки. И в моем представлении это проблема. Во-первых этот лут потом пылиться дома или, в лучшем случае, украшает офис. Во-вторых это достаточно весомый объем бюджета, который уходит в никуда
И тут Сбер на CodeFest сделал интересный эксперимент, вместо дорогого-красивого стенда и мягких игрушек сделал голый белый стенд. А вместо призов перенаправил бюджет на благотворительность! Каждый человек, который коммуницирует на стенде увеличивает размер фонда. А весь фонд по итогам конференции будет потрачен на технику в классе информатики для Новосибирского лицея №28
При этом, это не хуже работает на технобренд компании, но и приносит пользу обществу. Ну не красота-ли? Надеюсь, что и другие компании последуют этому примеру, а то весь этот мерч уже как не в коня корм.
https://conference-nsk.ru/
Что думаете, как еще можно в лучшую сторону изменить привычную коммуникацию компаний на конференциях?
Релизный процесс
Александр Свиридов. Руководитель мобильной разработки, озон тех.
Релиз раз в 5 рабочих дней (практически каждую неделю, могут влиять праздники).
В воскресенье начинается сбор ветки и запуск автотестов, к понедельнику тестеры получают результат прогона, вот такое начало недели.
Релиз менеджер отвечают за выпуск релиза, встречи по релизу каждый день.
Есть автоматизация релизного процесса.
Руками стараются не выкладывать.
Релизный портал Озона, агрегация всего про релиз - кто релиз мастер, скоуп, релиз ноутс и т.д.
Релиз катят частями и на 3 день катят на всех.
Как понимаем, что всё хорошо? Есть метрики, бизнес метрики в том числе в риалтайме. Через 3-4 часа после публикации релиза, сравниваем метрики по релизу, продуктовые метрики смотрим, всё смотрим в одно и тоже время (могут быть маркетинг акции и есть их влияние). Технические метрики также есть, перформанс метрики, например, как быстро откроется приложение. Смотрим Метрики коллег, озон банк, озон тревел.
Оповещения о проблемах.
Процесс, по этапам:
✅Релиз ветка
✅Релиз кандидат
✅Тест релиз кандидата
✅Выкладываем в вебсторы
✅И катим.
Может сломаться всё, на любом этапе процесса.
Баг в релиз процессе. Приоритет 0,1,2, что такое критический Баг очень чётко описано в том числе и в деньгах.
Отчет от релиз мастера - список тикетов, которые найдены с багами.
Что важно? Что делать, когда нашли баги?
Ничего, если не критический баг
Если 0 - то исправляем и пересобираем.
Если 1 - можем не делать, но обещаем в следующем релизе.
Фиксируем проблемы. У нас логика в большинстве своём перенесена с мобилы на бэкенд, так что нам на бэке быстрее пофиксить.
Часто можем в админке выключить фичу. Если не помогает, то переборка.
Скрипты выкладки могут сломаться.
Main событие, когда мы отклоняемся от релиз процесса, экстра - руками выкладка. Необычное могло привести к инциденту.
Выложили
Смотрим метрики, и по ним упали. Критикал линия на графике, инцидент менеджмент срабатывает, тогда подключается поддержка 24 на 7, тогда фиксят. Пост - инциденты разбираются.
Реджект в сторах
Минорные часто проблемы, например, неправильно описан релиз. Билд висит в сторе и ломает описание. 5-10% раскатки нам хватает, чтобы понять по метрикам успех релиза или нет на наших пользователях.
Лет за 5 завис релиз один раз для андроид, то есть происходит редко.
У нас есть база знаний отказов сторов. Что произошло, причина, кто и что делал тогда. И можем призвать юристов, для этого в базе можно найти какой юрист нужен и кто в прошлый раз помогал.
Ноябрь - декабрь сезон покупок, и это высокая нагрузка.
Релизы в сезон - фриз релизов на сезон, например, на месяц, релиза у нас нет. Делаем фейк релизы.
Всю рутину делаем по процессам релиза, кроме самого релиза. И эта практика помогает. И мы выкладываем в стор что есть. И после фриз мы получаем стабильный релиз.
Любой заказчик перед фризом хочет катит своё. Скоуп в 2-3 раза растёт.
Что делаем?
Чтобы не терять деньги от сбоев, мы вводим ограничение фичей 25,и всё!
Не ограничен предпоследний релиз. И это сильно помогает сбалансировать нагрузку и обеспечить стабильность. Мы объявляем заранее.
За месяц, за два объявление.
Продакты понимают когда и что катить.
Какие ещё ограничения?
Когда большой был рефакторинг, есть вероч появления фичи, которая может сломать всё. Мы лимитируем, что за неделю мы можем протестировать, только 1-2 такие сложные фичи, стабильность нам дороже. Такое никогда не выливаем в пятницу, надо чтобы помориновались неделю, чтобы найти критичные проблемы. Катить большие сложные фичи и не ломать расписание -наша ценность.
Если всё у вас хорошо.
Случается инцидент в год, 1-2 штуки, когда деньги теряем. Крэш на старте, например. Когда нет инцидентов, нет пищи на размышление.
Придумали внутренний инцидент.
Назвали всё, что приводит к сбою в процессе. Сломались скрипты, баги раскатки релиза... Есть встречи для разборов. И делаем артефакты, что нужно сделать, чтобы не допустить такие инцидентов. Собираем статистику за год.
Александр Свиридов. Руководитель мобильной разработки, озон тех.
Релиз раз в 5 рабочих дней (практически каждую неделю, могут влиять праздники).
В воскресенье начинается сбор ветки и запуск автотестов, к понедельнику тестеры получают результат прогона, вот такое начало недели.
Релиз менеджер отвечают за выпуск релиза, встречи по релизу каждый день.
Есть автоматизация релизного процесса.
Руками стараются не выкладывать.
Релизный портал Озона, агрегация всего про релиз - кто релиз мастер, скоуп, релиз ноутс и т.д.
Релиз катят частями и на 3 день катят на всех.
Как понимаем, что всё хорошо? Есть метрики, бизнес метрики в том числе в риалтайме. Через 3-4 часа после публикации релиза, сравниваем метрики по релизу, продуктовые метрики смотрим, всё смотрим в одно и тоже время (могут быть маркетинг акции и есть их влияние). Технические метрики также есть, перформанс метрики, например, как быстро откроется приложение. Смотрим Метрики коллег, озон банк, озон тревел.
Оповещения о проблемах.
Процесс, по этапам:
✅Релиз ветка
✅Релиз кандидат
✅Тест релиз кандидата
✅Выкладываем в вебсторы
✅И катим.
Может сломаться всё, на любом этапе процесса.
Баг в релиз процессе. Приоритет 0,1,2, что такое критический Баг очень чётко описано в том числе и в деньгах.
Отчет от релиз мастера - список тикетов, которые найдены с багами.
Что важно? Что делать, когда нашли баги?
Ничего, если не критический баг
Если 0 - то исправляем и пересобираем.
Если 1 - можем не делать, но обещаем в следующем релизе.
Фиксируем проблемы. У нас логика в большинстве своём перенесена с мобилы на бэкенд, так что нам на бэке быстрее пофиксить.
Часто можем в админке выключить фичу. Если не помогает, то переборка.
Скрипты выкладки могут сломаться.
Main событие, когда мы отклоняемся от релиз процесса, экстра - руками выкладка. Необычное могло привести к инциденту.
Выложили
Смотрим метрики, и по ним упали. Критикал линия на графике, инцидент менеджмент срабатывает, тогда подключается поддержка 24 на 7, тогда фиксят. Пост - инциденты разбираются.
Реджект в сторах
Минорные часто проблемы, например, неправильно описан релиз. Билд висит в сторе и ломает описание. 5-10% раскатки нам хватает, чтобы понять по метрикам успех релиза или нет на наших пользователях.
Лет за 5 завис релиз один раз для андроид, то есть происходит редко.
У нас есть база знаний отказов сторов. Что произошло, причина, кто и что делал тогда. И можем призвать юристов, для этого в базе можно найти какой юрист нужен и кто в прошлый раз помогал.
Ноябрь - декабрь сезон покупок, и это высокая нагрузка.
Релизы в сезон - фриз релизов на сезон, например, на месяц, релиза у нас нет. Делаем фейк релизы.
Всю рутину делаем по процессам релиза, кроме самого релиза. И эта практика помогает. И мы выкладываем в стор что есть. И после фриз мы получаем стабильный релиз.
Любой заказчик перед фризом хочет катит своё. Скоуп в 2-3 раза растёт.
Что делаем?
Чтобы не терять деньги от сбоев, мы вводим ограничение фичей 25,и всё!
Не ограничен предпоследний релиз. И это сильно помогает сбалансировать нагрузку и обеспечить стабильность. Мы объявляем заранее.
За месяц, за два объявление.
Продакты понимают когда и что катить.
Какие ещё ограничения?
Когда большой был рефакторинг, есть вероч появления фичи, которая может сломать всё. Мы лимитируем, что за неделю мы можем протестировать, только 1-2 такие сложные фичи, стабильность нам дороже. Такое никогда не выливаем в пятницу, надо чтобы помориновались неделю, чтобы найти критичные проблемы. Катить большие сложные фичи и не ломать расписание -наша ценность.
Если всё у вас хорошо.
Случается инцидент в год, 1-2 штуки, когда деньги теряем. Крэш на старте, например. Когда нет инцидентов, нет пищи на размышление.
Придумали внутренний инцидент.
Назвали всё, что приводит к сбою в процессе. Сломались скрипты, баги раскатки релиза... Есть встречи для разборов. И делаем артефакты, что нужно сделать, чтобы не допустить такие инцидентов. Собираем статистику за год.
Когда ввели такую практику, поняли много разных нюансов, например, что недостотаточно автотестов, не всё покрыто ими.
Пример из жизни.
Причина инцидента сломались скрипты, и тогда решили руками Билд выкладывать, и кое что отвалилось, оказывается просто тупой инцидент, я руками не тот файл выложил)
Релиз ничего не знает про фичи, всё что попало в релиз ветку, то и едет в релиз.
Охота на ведьм - культура компании позволяет нам адекватно подходить к работе. Если накосячил, то здоровая атмосфера от руководства и оно понимает, что есть всегда % инцидентов.
Считаем экономический эффект инцидента, это отдел аналитики, и это к Топ менеджерами, для анализа ситуации.
#CodeFest14 #релизы #доклад
Пример из жизни.
Причина инцидента сломались скрипты, и тогда решили руками Билд выкладывать, и кое что отвалилось, оказывается просто тупой инцидент, я руками не тот файл выложил)
Релиз ничего не знает про фичи, всё что попало в релиз ветку, то и едет в релиз.
Охота на ведьм - культура компании позволяет нам адекватно подходить к работе. Если накосячил, то здоровая атмосфера от руководства и оно понимает, что есть всегда % инцидентов.
Считаем экономический эффект инцидента, это отдел аналитики, и это к Топ менеджерами, для анализа ситуации.
#CodeFest14 #релизы #доклад
Впечатление от конференции ещё будет долго догонять, но вот первые мысли попробую сформулировать ❤️
1.Во-первых, очень было клёво смотреть на то, как горят глаза Евгения Галактионова, как он отдаёт конференции и секции системного анализа всего себя, это очень заряжает. Спасибо Евгений за возможность поучаствовать!)
2.Во вторых, конференция это общение, которого нам так не хватает. И его тут было много, и продолжается в чатах, переписках. Тот самый клёвый нетворкинг, когда любой эксперт на расстоянии вытянутой руки.
3.Я не понимаю, как, но Сибирь умеет окутывать каждого своей тёплой атмосферой, так, что улыбка не сходит с лица все два дня конференции.
4.И конечно про сами доклады и инсайты. Я поняла, как интересно делать такой скрининг, чем живёт айти-сфера, что болит, какие вопросы задают, как всё изменилось за последние годы. Много вопросов и обсуждений всё того же, как жить в нашем мире, где идёт борьба за наше время у корпораций, сервисов.
5.Очень любопытны доклады таких больших монстров, как Озон, ВК. Прослушала два доклада от Озон. Вывод, #капитаночевидность - у них в компании высокая степень зрелости процессов. И забавно, какие мы ноющие существа. Когда процессы черт знает какие, мы ноем и плачем, что как тяжело жить с этой дуростью, а когда процессы зрелые, кажется, что скучно и что ещё можно улучшить и сделать, если всё хорошо. И кажется, что ты будешь деградировать.
6.Ещё один вывод #капитаночевидность что крутые штуки получаются при адекватном бизнесе и адекватном подходе. Удивительные вещи когда люди могут говорить и договариваться!!! И прикиньте, это есть)))
7.Хочется сказать, что типа сеньору скучно на конфе, но нет, потому что это крутой способ вырваться из рутины, посмотреть вокруг и пересмотреть свой опыт. Понять, что ты не один и все на одной волне.
8.Интересно, как поменялись компании на стендах. Реально появились новые имена и я такая "фига, россельхоз банк это айти компания!" #внезапность
Моя поездка ещё не закончилась и я ещё буду собирать впечатление, пересматривать доклады. Переваривать эмоции. Но уже могу поблагодарить #CodeFest14 за то, что обнял и помог мне немного прийти в себя и искренне мне улыбнулся)))
1.Во-первых, очень было клёво смотреть на то, как горят глаза Евгения Галактионова, как он отдаёт конференции и секции системного анализа всего себя, это очень заряжает. Спасибо Евгений за возможность поучаствовать!)
2.Во вторых, конференция это общение, которого нам так не хватает. И его тут было много, и продолжается в чатах, переписках. Тот самый клёвый нетворкинг, когда любой эксперт на расстоянии вытянутой руки.
3.Я не понимаю, как, но Сибирь умеет окутывать каждого своей тёплой атмосферой, так, что улыбка не сходит с лица все два дня конференции.
4.И конечно про сами доклады и инсайты. Я поняла, как интересно делать такой скрининг, чем живёт айти-сфера, что болит, какие вопросы задают, как всё изменилось за последние годы. Много вопросов и обсуждений всё того же, как жить в нашем мире, где идёт борьба за наше время у корпораций, сервисов.
5.Очень любопытны доклады таких больших монстров, как Озон, ВК. Прослушала два доклада от Озон. Вывод, #капитаночевидность - у них в компании высокая степень зрелости процессов. И забавно, какие мы ноющие существа. Когда процессы черт знает какие, мы ноем и плачем, что как тяжело жить с этой дуростью, а когда процессы зрелые, кажется, что скучно и что ещё можно улучшить и сделать, если всё хорошо. И кажется, что ты будешь деградировать.
6.Ещё один вывод #капитаночевидность что крутые штуки получаются при адекватном бизнесе и адекватном подходе. Удивительные вещи когда люди могут говорить и договариваться!!! И прикиньте, это есть)))
7.Хочется сказать, что типа сеньору скучно на конфе, но нет, потому что это крутой способ вырваться из рутины, посмотреть вокруг и пересмотреть свой опыт. Понять, что ты не один и все на одной волне.
8.Интересно, как поменялись компании на стендах. Реально появились новые имена и я такая "фига, россельхоз банк это айти компания!" #внезапность
Моя поездка ещё не закончилась и я ещё буду собирать впечатление, пересматривать доклады. Переваривать эмоции. Но уже могу поблагодарить #CodeFest14 за то, что обнял и помог мне немного прийти в себя и искренне мне улыбнулся)))
Квартирники, митапы, мастер-классы, всё где есть активность всех собравшийхся, то что нам нужно. Чтобы за счёт общения развивать друг друга.
Спасибо за приглашение на квартирник! Вот впечатления от Татьяны)))
Спасибо за приглашение на квартирник! Вот впечатления от Татьяны)))
Forwarded from Да, мне больше всех надо
⏱ Как собрать круглый стол за 60 минут? ⏱
В один теплый день после просмотра десятого тестового задания и пары собеседований, мне очень захотелось обсудить тему подбора аналитиков.
С кем? И где? Назревала поездка в Новосибирск, там CodeFest. Через неделю.
Программа уже сформирована, но есть слоты под «народные квартирники».
А дальше было примерно так:
— Привет Андрей! Есть такая тема на поговорить....
— Аня, давай соберем квартирник, у меня все горит внутри, не могу молчать...
И моментом собрались в чатик, организовались и понеслось...
Созвонились, написали тезисы, отправили ПК. И таки да, попали в народную программу.
В итоге еще и участников квартирника стало больше — добавились Наташа и Евгений.
Мы последними в последний день конфы, и хотелось еще мнений послушать и с залом подольше поговорить, но как бы тайминг, все дела....
⏱ Какие выводы можно сделать?
1. Лучше попробовать и получить отказ, чем не попробовать. Да, даже если прием заявок закрыт или вашу идею не поддержат🙃
2. Если хочется выступать, то идите и пробуйте. Не будет того самого часа, который придет когда-нибудь. Считайте, что он уже наступил)
Что получилось, смотрите — Найти за 60 минут: как нанять хорошего аналитика
Спасибо, что поддержали мою идею, которая свалилась всем в последний момент — Наталья Косинова, Евгений Галактионов, Андрей Бураков, Анна Вичугова🧡
В один теплый день после просмотра десятого тестового задания и пары собеседований, мне очень захотелось обсудить тему подбора аналитиков.
С кем? И где? Назревала поездка в Новосибирск, там CodeFest. Через неделю.
Программа уже сформирована, но есть слоты под «народные квартирники».
А дальше было примерно так:
— Привет Андрей! Есть такая тема на поговорить....
— Аня, давай соберем квартирник, у меня все горит внутри, не могу молчать...
И моментом собрались в чатик, организовались и понеслось...
Созвонились, написали тезисы, отправили ПК. И таки да, попали в народную программу.
В итоге еще и участников квартирника стало больше — добавились Наташа и Евгений.
Мы последними в последний день конфы, и хотелось еще мнений послушать и с залом подольше поговорить, но как бы тайминг, все дела....
⏱ Какие выводы можно сделать?
1. Лучше попробовать и получить отказ, чем не попробовать. Да, даже если прием заявок закрыт или вашу идею не поддержат🙃
2. Если хочется выступать, то идите и пробуйте. Не будет того самого часа, который придет когда-нибудь. Считайте, что он уже наступил)
Что получилось, смотрите — Найти за 60 минут: как нанять хорошего аналитика
Спасибо, что поддержали мою идею, которая свалилась всем в последний момент — Наталья Косинова, Евгений Галактионов, Андрей Бураков, Анна Вичугова🧡
YouTube
Татьяна Бунто, Наталья Косинова, Евгений Галактионов, Андрей Бураков, Анна Вичугова. Найти за 60...
...минут: как нанять хорошего аналитика
- Обсудим какими самыми приоритетными компетенциями/скиллами должен обладать хороший аналитик;
- Обсудим, что по умолчанию должен уметь хороший аналитик в базовой сборке);
- Обменяемся мнениями, какие компетенции/скиллы…
- Обсудим какими самыми приоритетными компетенциями/скиллами должен обладать хороший аналитик;
- Обсудим, что по умолчанию должен уметь хороший аналитик в базовой сборке);
- Обменяемся мнениями, какие компетенции/скиллы…