Открытые вопросы
«А как бы ты решил эту проблему сам?» спросила меня коллега на тренинге по менторству. Вроде обычный вопрос, если бы не контекст: я играл роль менти, который пришел за помощью к ментору, а она была сама тем самым ментором, который должен был эту проблему решить. Я был удивлен таком вопросу и хотел сначала ответить «ну ты же ментор, ты и скажи» (так бы сказали многие, я уверен), но не стал спешить, а начал думать. И я придумал - решение моей задачи оказалось на поверхности, надо было лишь немного порефлексировать. Её вопрос запустил цепочку размышлений в моей голове - я связал причину и следствие, и это позволило мне найти ответ на свой вопрос.
Открытые вопросы (те, на которые нельзя ответить Да или Нет) лучше закрытых по многим причинам:
1. Позволяют получить более полную информацию. Вы получите более развернутый ответ от респондента, чем бинарный 0 или 1
2. Стимулируют размышление. Респондент задумается перед ответом на вопрос, это может привести его к новым идеям
3. Выявляют рассинхрон в видении проблемы. Очень часто очевидные для одного человека вещи будут неочевидны для другого. Открытые вопросы уменьшают риск появления данной проблемы за счет проговаривания вроде бы понятных моментов
4. Помогают принимать решения. Такие вопросы позволяют лучше понять ситуацию, собрать информацию и принять более взвешенное решение
Примеры закрытых/открытых вопросов:
- «Хотел бы ты расти в руководителя?» / «Кем ты видишь себя через год?»
- «Понравилось ли вам использовать нашу систему?» / «Расскажите, с какими трудностями вы столкнулись при использовании нашей системы.»
- «Есть ли у тебя проблемы с решением поставленной задачи?» / «Какой прогресс по этой задаче?»
Их можно использовать во многих ситуациях: на собеседованиях, в обучении, в опросах. Используя такие вопросы, вы сделаете мир чуточку понятнее.
@beyond_senior
«А как бы ты решил эту проблему сам?» спросила меня коллега на тренинге по менторству. Вроде обычный вопрос, если бы не контекст: я играл роль менти, который пришел за помощью к ментору, а она была сама тем самым ментором, который должен был эту проблему решить. Я был удивлен таком вопросу и хотел сначала ответить «ну ты же ментор, ты и скажи» (так бы сказали многие, я уверен), но не стал спешить, а начал думать. И я придумал - решение моей задачи оказалось на поверхности, надо было лишь немного порефлексировать. Её вопрос запустил цепочку размышлений в моей голове - я связал причину и следствие, и это позволило мне найти ответ на свой вопрос.
Открытые вопросы (те, на которые нельзя ответить Да или Нет) лучше закрытых по многим причинам:
1. Позволяют получить более полную информацию. Вы получите более развернутый ответ от респондента, чем бинарный 0 или 1
2. Стимулируют размышление. Респондент задумается перед ответом на вопрос, это может привести его к новым идеям
3. Выявляют рассинхрон в видении проблемы. Очень часто очевидные для одного человека вещи будут неочевидны для другого. Открытые вопросы уменьшают риск появления данной проблемы за счет проговаривания вроде бы понятных моментов
4. Помогают принимать решения. Такие вопросы позволяют лучше понять ситуацию, собрать информацию и принять более взвешенное решение
Примеры закрытых/открытых вопросов:
- «Хотел бы ты расти в руководителя?» / «Кем ты видишь себя через год?»
- «Понравилось ли вам использовать нашу систему?» / «Расскажите, с какими трудностями вы столкнулись при использовании нашей системы.»
- «Есть ли у тебя проблемы с решением поставленной задачи?» / «Какой прогресс по этой задаче?»
Их можно использовать во многих ситуациях: на собеседованиях, в обучении, в опросах. Используя такие вопросы, вы сделаете мир чуточку понятнее.
@beyond_senior
👍2🔥1👏1💯1
Давайте знакомиться!
Меня зовут Юра Тюрин. Я CTO в МД Аудит.
В IT c 2012 года. За это время успел поработать на многих ролях - разработчиком (в основном Backend, но немного и Web), DevOps, системным архитектором, тим-лидом. Участвовал в разработке множества проектов, например, мобильного приложения аэропорта Домодедово или приложения ТЦ Мега. Последние 7 лет я занимаюсь развитием продукта МД Аудит, из них 3 года в качестве технического директора.
С 22 года занимаюсь менторством - помогаю в вопросах организации процессов разработки, построении команд, внедрении DevOps процессов и достижении карьерных целей. За два года помог как минимум 50 людям и не планирую останавливаться на этом.
Люблю путешествовать - до ковида посетил 15 стран, а после увлекся путешествиями по России (Алтай, Курилы, Карелия - в моем сердце). Веду активный образ жизни - летом SUP и велосипеды, зимой - горные лыжи, в межсезонье - прогулки и походы.
Канал я назвал "Выше синьора", так как на своем опыте знаю как сложно найти точки роста, когда ты добрался до уровня эксперта, но уперся в "стеклянный потолок". Буду писать о своих шишках, которые набил по пути к CTO и о подходах, которые использую в работе.
Надеюсь будет интересно!
@beyond_senior
Меня зовут Юра Тюрин. Я CTO в МД Аудит.
В IT c 2012 года. За это время успел поработать на многих ролях - разработчиком (в основном Backend, но немного и Web), DevOps, системным архитектором, тим-лидом. Участвовал в разработке множества проектов, например, мобильного приложения аэропорта Домодедово или приложения ТЦ Мега. Последние 7 лет я занимаюсь развитием продукта МД Аудит, из них 3 года в качестве технического директора.
С 22 года занимаюсь менторством - помогаю в вопросах организации процессов разработки, построении команд, внедрении DevOps процессов и достижении карьерных целей. За два года помог как минимум 50 людям и не планирую останавливаться на этом.
Люблю путешествовать - до ковида посетил 15 стран, а после увлекся путешествиями по России (Алтай, Курилы, Карелия - в моем сердце). Веду активный образ жизни - летом SUP и велосипеды, зимой - горные лыжи, в межсезонье - прогулки и походы.
Канал я назвал "Выше синьора", так как на своем опыте знаю как сложно найти точки роста, когда ты добрался до уровня эксперта, но уперся в "стеклянный потолок". Буду писать о своих шишках, которые набил по пути к CTO и о подходах, которые использую в работе.
Надеюсь будет интересно!
@beyond_senior
MD Audit
MD Audit | Система для аудита розничной сети
MD Audit — Система для аудита розничной сети и управления персоналом в торговых точках, контроля соблюдения стандартов по чек-листам, анализ промо-кампаний, управления задачами и учета рабочего времени
👍4🔥1🤝1
Кто такой СТО
Роль СТО в IT’шных кругах одна из самых загадочных - очень мало людей могут уверенно сказать, чем конкретно занимается СТО. Толи это самый крутой разработчик в компании, то ли менеджер, то ли все вместе. Даже вступив на эту должность, мне потребовалось много времени на осознание истинной ценности этой роли. Давайте попробуем разобраться.
СТО (технический директор) - это C-Level, отвечающий за технологические продукты в компании. Это может быть программный продукт, разрабатываемый ИТ компанией, интернет-магазин в розничной сети, станки и обслуживающее их ПО на заводе. Но везде это что-то, что требует глубоких знаний технологий и приносит непосредственную прибыль компании. Без этих двух факторов роль СТО просто не имеет смысла.
Чтобы понять задачи СТО, давайте пойдем от обратного - посмотрим чем он заниматься не должен. Хочу оговориться, что на начальной стадии зрелости компании, когда команда еще небольшая, СТО в том числе может брать на себя эти задачи (я до сих пор выполняю часть из этого списка), но при росте компании они по-хорошем должны быть делегированы, иначе есть риск закопаться в рутине, но упустить из фокуса самое главное - продукт.
Чем не должен заниматься СТО:
- Бек-офисом. Он не закупает ноутбуки, не меняет картриджи, и не отвечает за работу почты. Это должна быть сфера влияния ИТ-директора или ИТ-отдела.
- Проектным менеджментом. Он не создает и контролирует выполнение задач, не пишет ТЗ, не общается с заказчиками. Для этого есть Project Manager или Тим-Лид.
- Разработкой. Это прям бич многих СТО, кто вырос из разработчиков (мой в том числе) - желание заняться любимым и привычным делом, вместо вот этого вот всего менеджерского. Но разработка - это не только процесс написания кода, но и фикс багов, внесение изменений, поддержка. Пару часов, проведенных за кодингом, могут стоить нескольких недель поддержки, а это время, которое можно потратить на что-то более ценное.
- Продуктологией. Определять какие фичи из беклога будут наиболее полезны клиенту - это задача продуктолога. СТО же должен построить "рельсы", чтобы процесс создания новых фичей выполнялся как можно более эффективно.
Теперь про то, что все-таки входит в обязанности СТО:
1️⃣ Выбор технологического стека продукта. Какой язык и фреймворки используем, какую БД и тд. Тут важно учитывать не только пользу от технологии, но и риски, которые она несет. Например, риск ограничения доступа из-за санкций или сложность в найме специалистов, знакомых с ней.
2️⃣ Разработка архитектуры продукта, способной масштабироваться под потребности бизнеса. Нужно быть готовым к кратным увеличениям количества пользователей или внезапным изменениям направления развития продукта
3️⃣ Обеспечение качества работы системы на должном уровне. Стабильность, качество, скорость работы, безопасность продукта - вот те критерии, которые влияют на удовлетворенность пользователей, а значит и на прибыль компании. СТО важно контролировать эти метрики и выстраивать процессы таким образом, чтобы они не опускались ниже гигиенического уровня.
4️⃣ Создание процессов разработки, обеспечивающих высокий Time to market, при этом без потери в качестве. Код ревью, автоматизация тестирования, внедрение CI/CD, новых инструментов - все это позволит команде работать эффективнее и быстрее достигать целей бизнеса.
5️⃣ Организация команд, способных развивать и поддерживать систему, при этом способную адаптироваться к потребностям бизнеса. Найм, увольнение, развитие сотрудников - важная часть работы СТО
Надеюсь я немного пролил свет на роль СТО. В одной из следующих статей расскажу про то, что нужно, чтобы стать СТО.
Всем хорошего вечера!
@beyond_senior
Роль СТО в IT’шных кругах одна из самых загадочных - очень мало людей могут уверенно сказать, чем конкретно занимается СТО. Толи это самый крутой разработчик в компании, то ли менеджер, то ли все вместе. Даже вступив на эту должность, мне потребовалось много времени на осознание истинной ценности этой роли. Давайте попробуем разобраться.
СТО (технический директор) - это C-Level, отвечающий за технологические продукты в компании. Это может быть программный продукт, разрабатываемый ИТ компанией, интернет-магазин в розничной сети, станки и обслуживающее их ПО на заводе. Но везде это что-то, что требует глубоких знаний технологий и приносит непосредственную прибыль компании. Без этих двух факторов роль СТО просто не имеет смысла.
Чтобы понять задачи СТО, давайте пойдем от обратного - посмотрим чем он заниматься не должен. Хочу оговориться, что на начальной стадии зрелости компании, когда команда еще небольшая, СТО в том числе может брать на себя эти задачи (я до сих пор выполняю часть из этого списка), но при росте компании они по-хорошем должны быть делегированы, иначе есть риск закопаться в рутине, но упустить из фокуса самое главное - продукт.
Чем не должен заниматься СТО:
- Бек-офисом. Он не закупает ноутбуки, не меняет картриджи, и не отвечает за работу почты. Это должна быть сфера влияния ИТ-директора или ИТ-отдела.
- Проектным менеджментом. Он не создает и контролирует выполнение задач, не пишет ТЗ, не общается с заказчиками. Для этого есть Project Manager или Тим-Лид.
- Разработкой. Это прям бич многих СТО, кто вырос из разработчиков (мой в том числе) - желание заняться любимым и привычным делом, вместо вот этого вот всего менеджерского. Но разработка - это не только процесс написания кода, но и фикс багов, внесение изменений, поддержка. Пару часов, проведенных за кодингом, могут стоить нескольких недель поддержки, а это время, которое можно потратить на что-то более ценное.
- Продуктологией. Определять какие фичи из беклога будут наиболее полезны клиенту - это задача продуктолога. СТО же должен построить "рельсы", чтобы процесс создания новых фичей выполнялся как можно более эффективно.
Теперь про то, что все-таки входит в обязанности СТО:
1️⃣ Выбор технологического стека продукта. Какой язык и фреймворки используем, какую БД и тд. Тут важно учитывать не только пользу от технологии, но и риски, которые она несет. Например, риск ограничения доступа из-за санкций или сложность в найме специалистов, знакомых с ней.
2️⃣ Разработка архитектуры продукта, способной масштабироваться под потребности бизнеса. Нужно быть готовым к кратным увеличениям количества пользователей или внезапным изменениям направления развития продукта
3️⃣ Обеспечение качества работы системы на должном уровне. Стабильность, качество, скорость работы, безопасность продукта - вот те критерии, которые влияют на удовлетворенность пользователей, а значит и на прибыль компании. СТО важно контролировать эти метрики и выстраивать процессы таким образом, чтобы они не опускались ниже гигиенического уровня.
4️⃣ Создание процессов разработки, обеспечивающих высокий Time to market, при этом без потери в качестве. Код ревью, автоматизация тестирования, внедрение CI/CD, новых инструментов - все это позволит команде работать эффективнее и быстрее достигать целей бизнеса.
5️⃣ Организация команд, способных развивать и поддерживать систему, при этом способную адаптироваться к потребностям бизнеса. Найм, увольнение, развитие сотрудников - важная часть работы СТО
Надеюсь я немного пролил свет на роль СТО. В одной из следующих статей расскажу про то, что нужно, чтобы стать СТО.
Всем хорошего вечера!
@beyond_senior
🔥6👍4💯2🍓1
Факторы мотивации
Когда я стал руководителем, одной из самых больших сложностей для меня было понимание факторов, влияющих на мотивацию сотрудников.
Из университетского курса по менеджменту я помнил только пирамиду Маслоу. Она выстраивает группы потребностей индивида по мере уменьшения важности - в самом низу физические потребности (еда, вода, воздух), далее идут потребности в безопасности и уверенности в завтрашнем дне, после - социальные связи (друзья, родные), а затем уже признание и самовыражение. Причем потребность более высокого уровня не будет возникать, пока не закрыта потребность более низкого уровня. Я не буду думать о саморазвитии, когда мне негде жить и живот урчит от голода. Вопрос в том, как это применить на практике. Вот сидят Вася и Петя, вроде все базовые потребности у них закрыты - есть работа, хорошая зарплата, семья. Почему один из них работает лучше другого?
На самом деле, пирамида Маслоу плохо применима к корпоративной среде. Чтобы понять факторы мотивации, лучше будет обратиться к теории Герцберга. Она заключается в том, что факторы мотивации сотрудников делятся на два типа: гигиенические и мотивирующие.
Гигиенические факторы - те факторы, отсутствие которых или нахождение ниже ожидаемого уровня будет негативно сказываться на мотивации человека, но повышение их выше ожидаемого уровня никак на мотивацию влиять не будут. Например, стул. Если я буду работать на неудобном или скрипящем стуле, то мне будет некомфортно и вряд ли я смогу продуктивно работать. Но если у меня уже есть хороший стул, то покупка нового, хоть и в 5 раз дороже, не сильно увеличит мою производительность.
Немного не интуитивно, но к гигиеническим факторам относится и зарплата. Если моей зарплаты достаточно для покрытия большинства моих потребностей, то я не соглашусь на менее приятную работу, даже если мне предложат больше денег. Но если мои потребности повысятся, например появится ребенок или ипотека, и текущей зарплаты мне будет не хватать, то я уже буду задумываться о смене работы, пускай она и будет менее желанной.
Мотивирующие факторы, напротив, сильно влияют на уровень удовлетворенности. Чем выше находится уровень этих факторов, тем более мотивированным становится сотрудник. К ним относятся - признание успеха (все мы любим, когда нас хвалят), повышение в должности, понимание значимости работы, свобода в выборе решения, возможность развития и т.д. Для каждого сотрудника эти факторы будут индивидуальны: одним важно делать сложные задачи, другим - когда их хвалят. Цель руководителя - понять, что важно для каждого отдельно взятого сотрудника, и как он может на это повлиять.
Обе эти группы факторов одинаково важны - нужно следить за гигиеническими факторами, и добавлять мотивирующие, тогда ваши сотрудники будут счастливы и готовы к новым победам. Всем успеха!
@beyond_senior
Когда я стал руководителем, одной из самых больших сложностей для меня было понимание факторов, влияющих на мотивацию сотрудников.
Из университетского курса по менеджменту я помнил только пирамиду Маслоу. Она выстраивает группы потребностей индивида по мере уменьшения важности - в самом низу физические потребности (еда, вода, воздух), далее идут потребности в безопасности и уверенности в завтрашнем дне, после - социальные связи (друзья, родные), а затем уже признание и самовыражение. Причем потребность более высокого уровня не будет возникать, пока не закрыта потребность более низкого уровня. Я не буду думать о саморазвитии, когда мне негде жить и живот урчит от голода. Вопрос в том, как это применить на практике. Вот сидят Вася и Петя, вроде все базовые потребности у них закрыты - есть работа, хорошая зарплата, семья. Почему один из них работает лучше другого?
На самом деле, пирамида Маслоу плохо применима к корпоративной среде. Чтобы понять факторы мотивации, лучше будет обратиться к теории Герцберга. Она заключается в том, что факторы мотивации сотрудников делятся на два типа: гигиенические и мотивирующие.
Гигиенические факторы - те факторы, отсутствие которых или нахождение ниже ожидаемого уровня будет негативно сказываться на мотивации человека, но повышение их выше ожидаемого уровня никак на мотивацию влиять не будут. Например, стул. Если я буду работать на неудобном или скрипящем стуле, то мне будет некомфортно и вряд ли я смогу продуктивно работать. Но если у меня уже есть хороший стул, то покупка нового, хоть и в 5 раз дороже, не сильно увеличит мою производительность.
Немного не интуитивно, но к гигиеническим факторам относится и зарплата. Если моей зарплаты достаточно для покрытия большинства моих потребностей, то я не соглашусь на менее приятную работу, даже если мне предложат больше денег. Но если мои потребности повысятся, например появится ребенок или ипотека, и текущей зарплаты мне будет не хватать, то я уже буду задумываться о смене работы, пускай она и будет менее желанной.
Мотивирующие факторы, напротив, сильно влияют на уровень удовлетворенности. Чем выше находится уровень этих факторов, тем более мотивированным становится сотрудник. К ним относятся - признание успеха (все мы любим, когда нас хвалят), повышение в должности, понимание значимости работы, свобода в выборе решения, возможность развития и т.д. Для каждого сотрудника эти факторы будут индивидуальны: одним важно делать сложные задачи, другим - когда их хвалят. Цель руководителя - понять, что важно для каждого отдельно взятого сотрудника, и как он может на это повлиять.
Обе эти группы факторов одинаково важны - нужно следить за гигиеническими факторами, и добавлять мотивирующие, тогда ваши сотрудники будут счастливы и готовы к новым победам. Всем успеха!
@beyond_senior
👍6🔥4💯2
Продуктовый подход при проектировании фичей в b2b
К нам в МД Аудит часто приходят наши клиенты с просьбой за деньги доработать нашу систему под их нужды - добавить отчет, автоматизировать их бизнес-процесс и т.д. В заказной разработке это требовало бы классического пути - написания технического задания, оценка трудозатрат и сроков реализации, подготовка коммерческого предложения, реализация, ну и так далее. Причем заработок идет за счет маржи - разницей между внутренней оценкой и той, что предоставляется заказчику, и может составлять от 50/100/200% в зависимости от рисков проекта. Но мы не студия, а продуктовая компания, по-этому у нас немного другие подходы - мы стараемся найти такой вариант решения проблемы клиента, от которого пришел запрос, чтобы он был потенциально полезным и для других наших клиентов. Как это происходит?
После получения запроса от заказчика и анализа бизнес требований мы организуем встречу, на которой присутствуют минимум две роли - продакт и архитектор. Продакт отвечает за видение с точки зрения продукта, а архитектор - с технической точки зрения. Если задача очевидная и решается только одним способом (например, добавить информацию в отчет), то мы выполняем оценку трудозатрат и сроков, готовим описание реализации для клиента и, что очень важно, подсвечиваем полезность этой доработки для других клиентов. Этот отчет мы отправляем аккаунт-менеджеру, который дальше рассчитывает конечную стоимость доработки для заказчика исходя из разных факторов: платежеспособности клиента, его ожиданий, важности сделки и т.д. Если аккаунт-менеджер понимает, что клиент не готов заплатить за эту доработку, то эта самая полезность дает ему возможность быть более гибким в ценообразовании - сделать скидку или поискать других заинтересованных клиентов, чтобы разделить стоимость пополам.
Если вариантов решения проблемы клиента может быть несколько, то мы стараемся дать два варианта: вариант "в лоб", который не несет пользы другим клиентам, но можно сделать за короткое время, и "полезный" вариант. Причем вариант "в лоб" часто имеет еще и технические ограничения, например, за счет того, что мы используем Low-Code или костыли, что мы обязательно подсвечиваем в отчете, но в некоторых случаях быстрое и дешевое решение может сильно повысить лояльность клиента, а это значительно важнее моментального заработка.
Такой подход позволяет снизить стоимость разработки для клиента до себестоимости, а иногда и ниже, так как прибыль компании формируется за счет подписок и лицензий, а заказная разработка - это, скорее, способ добавить ценность продукту, что в долгосрочной перспективе принесет еще большую прибыль.
@beyond_senior
К нам в МД Аудит часто приходят наши клиенты с просьбой за деньги доработать нашу систему под их нужды - добавить отчет, автоматизировать их бизнес-процесс и т.д. В заказной разработке это требовало бы классического пути - написания технического задания, оценка трудозатрат и сроков реализации, подготовка коммерческого предложения, реализация, ну и так далее. Причем заработок идет за счет маржи - разницей между внутренней оценкой и той, что предоставляется заказчику, и может составлять от 50/100/200% в зависимости от рисков проекта. Но мы не студия, а продуктовая компания, по-этому у нас немного другие подходы - мы стараемся найти такой вариант решения проблемы клиента, от которого пришел запрос, чтобы он был потенциально полезным и для других наших клиентов. Как это происходит?
После получения запроса от заказчика и анализа бизнес требований мы организуем встречу, на которой присутствуют минимум две роли - продакт и архитектор. Продакт отвечает за видение с точки зрения продукта, а архитектор - с технической точки зрения. Если задача очевидная и решается только одним способом (например, добавить информацию в отчет), то мы выполняем оценку трудозатрат и сроков, готовим описание реализации для клиента и, что очень важно, подсвечиваем полезность этой доработки для других клиентов. Этот отчет мы отправляем аккаунт-менеджеру, который дальше рассчитывает конечную стоимость доработки для заказчика исходя из разных факторов: платежеспособности клиента, его ожиданий, важности сделки и т.д. Если аккаунт-менеджер понимает, что клиент не готов заплатить за эту доработку, то эта самая полезность дает ему возможность быть более гибким в ценообразовании - сделать скидку или поискать других заинтересованных клиентов, чтобы разделить стоимость пополам.
Если вариантов решения проблемы клиента может быть несколько, то мы стараемся дать два варианта: вариант "в лоб", который не несет пользы другим клиентам, но можно сделать за короткое время, и "полезный" вариант. Причем вариант "в лоб" часто имеет еще и технические ограничения, например, за счет того, что мы используем Low-Code или костыли, что мы обязательно подсвечиваем в отчете, но в некоторых случаях быстрое и дешевое решение может сильно повысить лояльность клиента, а это значительно важнее моментального заработка.
Такой подход позволяет снизить стоимость разработки для клиента до себестоимости, а иногда и ниже, так как прибыль компании формируется за счет подписок и лицензий, а заказная разработка - это, скорее, способ добавить ценность продукту, что в долгосрочной перспективе принесет еще большую прибыль.
@beyond_senior
👍10🔥3👏1