Про отдых и выгорание
Совсем скоро я планирую отправиться в недолгий отпуск. И сколько себя помню - всегда относился к своим отпускам стратегически: рассматривал их не сколько как развлекуху, сколько как инвестицию в свою будущую работоспособность и энергичность, ведь если я норм отдохну, то у меня появятся силы достигать! Этот подход не лишен недостатков - например, слишком серьезное отношение к отдыху создает напряженность, что в свою очередь только вредит его качеству. Однако мне 30+, я сохранил работоспособность и энтузиазм - значит это как-то работает:)
Многие пишут, что качественно отдыхать не менее важно, чем качественно работать, и я полностью согласен с этим. Ведь если плохо отдыхать, то не будет энергии, выгоришь, станешь развалюхой - а они никому не нужны, с такими людьми мало кто хочет иметь дело. Не хочется быть таким человеком.
Переломным моментом в своем взгляде на отдых я считаю момент, когда я прям осознал, что НИКТО В МИРЕ не позаботится всерьез о моем отдыхе, кроме меня самого. Друзья могут посетовать на синяки под глазами и вялость, но они не заставят меня организовать себе отпуск - сильно настаивать в этой сфере не принято. Семья тоже может не видеть в этом проблемы пока ты более-менее делаешь все, что должен. Вот и получается, что никто не придет тебя спасать от выгорания - заботиться об этом нужно самому.
Как одну из небольших мер против заценил для себя практику вечерних прогулок - выхожу гулять и по ходу дела мысленно отвечаю себе на 3 вопроса:
1. Что хорошего было в этом дне?
2. За что я благодарен сегодня?
3. В чем бы я мог быть получше сегодня?
Иногда сам удивляюсь тому, какие цепочки мыслей возникают. Такое внутреннее обсуждение помогает осмыслить и переживать каждый конкретный день со всеми его вопросиками. Попробуйте, вдруг и вам зайдет.
Совсем скоро я планирую отправиться в недолгий отпуск. И сколько себя помню - всегда относился к своим отпускам стратегически: рассматривал их не сколько как развлекуху, сколько как инвестицию в свою будущую работоспособность и энергичность, ведь если я норм отдохну, то у меня появятся силы достигать! Этот подход не лишен недостатков - например, слишком серьезное отношение к отдыху создает напряженность, что в свою очередь только вредит его качеству. Однако мне 30+, я сохранил работоспособность и энтузиазм - значит это как-то работает:)
Многие пишут, что качественно отдыхать не менее важно, чем качественно работать, и я полностью согласен с этим. Ведь если плохо отдыхать, то не будет энергии, выгоришь, станешь развалюхой - а они никому не нужны, с такими людьми мало кто хочет иметь дело. Не хочется быть таким человеком.
Переломным моментом в своем взгляде на отдых я считаю момент, когда я прям осознал, что НИКТО В МИРЕ не позаботится всерьез о моем отдыхе, кроме меня самого. Друзья могут посетовать на синяки под глазами и вялость, но они не заставят меня организовать себе отпуск - сильно настаивать в этой сфере не принято. Семья тоже может не видеть в этом проблемы пока ты более-менее делаешь все, что должен. Вот и получается, что никто не придет тебя спасать от выгорания - заботиться об этом нужно самому.
Как одну из небольших мер против заценил для себя практику вечерних прогулок - выхожу гулять и по ходу дела мысленно отвечаю себе на 3 вопроса:
1. Что хорошего было в этом дне?
2. За что я благодарен сегодня?
3. В чем бы я мог быть получше сегодня?
Иногда сам удивляюсь тому, какие цепочки мыслей возникают. Такое внутреннее обсуждение помогает осмыслить и переживать каждый конкретный день со всеми его вопросиками. Попробуйте, вдруг и вам зайдет.
❤15🔥7
Про перебивания
Любой менеджер продукта, хоть технический, хоть нет, часто участвует в обсуждениях - планов, фичей, проблем, людей и т.д. И, работая в разных компаниях, я наблюдаю как по-разному команды относятся к перебиванию друг друга в этих обсуждениях. В одних компаниях все обязательно пользуются фичами "Поднять руку" на онлайн-встречах и ждут своей очереди, в других "токен" на высказывание получает тот, кто громче и наглее. В одних говорящему всегда дают высказать свою мысль до конца, в других запросто перебивают и вставляют комментарии прямо по ходу повествования другого человека.
И ведь интересно, что при обоих подходах я НЕ наблюдаю, что бы хоть один из них радикально негативно влиял на результативность общего дела. Казалось бы, если перебивать и не давать высказать важную мысль, то это может сыграть в минус дважды:
1. Страдает вовлеченность человека. Он видит, что его мнение не слушают и перестанет вовлекаться в обсуждения.
2. Можно упустить действительно важный комментарий, который окажет негативное влияние на ход событий.
При том, что я терпеть не могу, когда перебивают меня или других людей при мне - я видел, что "перебивающие" команды двигались вперед и достигали достойного результата. Конечно, я тут немного сравниваю черное и белое - в реальности оттенков намного больше. В командах есть разные люди, которые могут вести себя по-разному в разных обстоятельствах.
Для себя я вывел пару принципов поведения в таких ситуациях:
1. Для достижения результата мне нужно уметь подстроиться под собеседников, а не ломать их своим представлением о коммуникации. Если принято перебивать - штош, надо тоже не стесняться (мне это дается сложно) Если принято давать больше пространства - тоже ок.
2. Если меня перебивают в процессе действительно важной мысли (важной по моему мнению, конечно), то явно обозначаю границу в духе "Дай, пожалуйста, я договорю" или "Педро, не перебивай меня, пожалуйста". В большинстве случаев этого достаточно не только для того, что бы договорить текущую мысль, но и на весь разговор.
3. Если на встрече участники часто перебивают, и темы уходят все дальше от той, по которой я хотел что-то сказать, то стараюсь сразу же записать куда-то мысль или вопрос, чтобы при следующей возможности вернуться к интересующей теме, если она действительно важна для меня.
К слову, зачастую бывает так, что намного полезнее не бороться за пространство в разговоре, а остановиться и послушать мета-информацию - кто за что борется, кто чего избегает, кто к чьему мнению (не) прислушивается. Иногда эти наблюдения помогают в дальнейшем не меньше, чем влияние на русло разговора.
Любой менеджер продукта, хоть технический, хоть нет, часто участвует в обсуждениях - планов, фичей, проблем, людей и т.д. И, работая в разных компаниях, я наблюдаю как по-разному команды относятся к перебиванию друг друга в этих обсуждениях. В одних компаниях все обязательно пользуются фичами "Поднять руку" на онлайн-встречах и ждут своей очереди, в других "токен" на высказывание получает тот, кто громче и наглее. В одних говорящему всегда дают высказать свою мысль до конца, в других запросто перебивают и вставляют комментарии прямо по ходу повествования другого человека.
И ведь интересно, что при обоих подходах я НЕ наблюдаю, что бы хоть один из них радикально негативно влиял на результативность общего дела. Казалось бы, если перебивать и не давать высказать важную мысль, то это может сыграть в минус дважды:
1. Страдает вовлеченность человека. Он видит, что его мнение не слушают и перестанет вовлекаться в обсуждения.
2. Можно упустить действительно важный комментарий, который окажет негативное влияние на ход событий.
При том, что я терпеть не могу, когда перебивают меня или других людей при мне - я видел, что "перебивающие" команды двигались вперед и достигали достойного результата. Конечно, я тут немного сравниваю черное и белое - в реальности оттенков намного больше. В командах есть разные люди, которые могут вести себя по-разному в разных обстоятельствах.
Для себя я вывел пару принципов поведения в таких ситуациях:
1. Для достижения результата мне нужно уметь подстроиться под собеседников, а не ломать их своим представлением о коммуникации. Если принято перебивать - штош, надо тоже не стесняться (мне это дается сложно) Если принято давать больше пространства - тоже ок.
2. Если меня перебивают в процессе действительно важной мысли (важной по моему мнению, конечно), то явно обозначаю границу в духе "Дай, пожалуйста, я договорю" или "Педро, не перебивай меня, пожалуйста". В большинстве случаев этого достаточно не только для того, что бы договорить текущую мысль, но и на весь разговор.
3. Если на встрече участники часто перебивают, и темы уходят все дальше от той, по которой я хотел что-то сказать, то стараюсь сразу же записать куда-то мысль или вопрос, чтобы при следующей возможности вернуться к интересующей теме, если она действительно важна для меня.
К слову, зачастую бывает так, что намного полезнее не бороться за пространство в разговоре, а остановиться и послушать мета-информацию - кто за что борется, кто чего избегает, кто к чьему мнению (не) прислушивается. Иногда эти наблюдения помогают в дальнейшем не меньше, чем влияние на русло разговора.
👍17❤7
Про кастомные доработки в платформах
Одним из вызовов при разработке инженерных платформ в больших компаниях является тема кастомных доработок. У вас есть платформа, которой пользуются десятки или сотни команд. И сценарий обычно один и тот же - приходит большой и влиятельный внутренний клиент (команда, департамент, whatever) и просит сделать такую фичу в платформе, которая действительно будет полезна и ценна для него. Однако проблема в том, что зачастую эта функция не нужна НИКОМУ из пользователей платформы, кроме него. Она будет использоваться эксклюзивно этим большим клиентом.
Сделали такую доработку один раз. Потом еще разок. И ведь нельзя сказать, что пользы нет - большой и важный клиент действительно решает свою задачу с помощью этих фич и в итоге больше зарабатывает или меньше тратит на уровне компании. А разве не для этого и существуют платформы в больших компаниях?! И отказать тоже непросто - отказ делать кастомные штуки может спровоцировать политический конфликт. Отношения с влиятельным клиентом могут стать натянутыми. Он может начать задумываться о разработке собственного решения, что ослабит позиции платформы в компании. И что делать менеджеру платформы в такой ситуации?
Универсального ответа тут не существует, но мне кажется, что смысл имеет следующее:
0.Потрогать траву и успокоиться
1. В каком-то виде заручиться поддержкой руководства т.к. возможно будет эскалация - будет круто, если руководство вам доверяет и знает, что вы не сделаете хрень.
2. Проверить расчеты ценности от кастомной доработки, если они вообще есть. Может оказаться так, что на деле они основаны на очень оптимистичных предположениях или не учитывают какие-то факторы. Если тут обнаружатся несостыковки, они пригодятся на следующих этапах. Например, может оказаться, что в основе предположение роста x3 в год, а на деле вы ждете x1,5.
3. Подумать, есть ли такая мера обобщения предложенной фичи, в которой она будет полезна не только этому клиенту? Есть ли возможность сделать из кастомной идеи такой общий функционал, который даст ценность другим пользователям? Например, клиент хочет показывать в UI статус из какой-то кастомной системы, которая есть только у него. Обобщенный функционал мог бы выглядеть как возможность редактировать виджеты на странице, и одним из виджетов был бы виджет для статусов из той самой системы этого клиента. Таким образом ВСЕ пользователи получили бы возможность менять вид страницы под свои задачи с помощью виджетов, и важный клиент в их числе.
4. Достаточно подробно объяснить важному клиенту почему именно вы отказали ему в фиче. Важно, чтобы он понял, что вы не самодур, а действительно его цените (цените же?) и при этом следите за качеством платформы для всех пользователей. Если у вас будут на руках те самые несостыковки и какие-то цифры, которые покажут потенциал последствия от кастома - покажите их, хоть они тут и не главные.
5. Приготовиться к давлению. Если важный клиент настойчив, то он может в каком-то виде начать давить на вас (в корпорациях это могут делать тонко). Кмк, тут важно сохранить фокус на будущем сотрудничестве и не допустить, чтобы этот конфликт стал деструктивным. Это непросто.
А вообще, работа в платформах это довольно специфичная история. Надо будет об этом еще написать что ли...
Одним из вызовов при разработке инженерных платформ в больших компаниях является тема кастомных доработок. У вас есть платформа, которой пользуются десятки или сотни команд. И сценарий обычно один и тот же - приходит большой и влиятельный внутренний клиент (команда, департамент, whatever) и просит сделать такую фичу в платформе, которая действительно будет полезна и ценна для него. Однако проблема в том, что зачастую эта функция не нужна НИКОМУ из пользователей платформы, кроме него. Она будет использоваться эксклюзивно этим большим клиентом.
Сделали такую доработку один раз. Потом еще разок. И ведь нельзя сказать, что пользы нет - большой и важный клиент действительно решает свою задачу с помощью этих фич и в итоге больше зарабатывает или меньше тратит на уровне компании. А разве не для этого и существуют платформы в больших компаниях?! И отказать тоже непросто - отказ делать кастомные штуки может спровоцировать политический конфликт. Отношения с влиятельным клиентом могут стать натянутыми. Он может начать задумываться о разработке собственного решения, что ослабит позиции платформы в компании. И что делать менеджеру платформы в такой ситуации?
Универсального ответа тут не существует, но мне кажется, что смысл имеет следующее:
0.
1. В каком-то виде заручиться поддержкой руководства т.к. возможно будет эскалация - будет круто, если руководство вам доверяет и знает, что вы не сделаете хрень.
2. Проверить расчеты ценности от кастомной доработки, если они вообще есть. Может оказаться так, что на деле они основаны на очень оптимистичных предположениях или не учитывают какие-то факторы. Если тут обнаружатся несостыковки, они пригодятся на следующих этапах. Например, может оказаться, что в основе предположение роста x3 в год, а на деле вы ждете x1,5.
3. Подумать, есть ли такая мера обобщения предложенной фичи, в которой она будет полезна не только этому клиенту? Есть ли возможность сделать из кастомной идеи такой общий функционал, который даст ценность другим пользователям? Например, клиент хочет показывать в UI статус из какой-то кастомной системы, которая есть только у него. Обобщенный функционал мог бы выглядеть как возможность редактировать виджеты на странице, и одним из виджетов был бы виджет для статусов из той самой системы этого клиента. Таким образом ВСЕ пользователи получили бы возможность менять вид страницы под свои задачи с помощью виджетов, и важный клиент в их числе.
4. Достаточно подробно объяснить важному клиенту почему именно вы отказали ему в фиче. Важно, чтобы он понял, что вы не самодур, а действительно его цените (цените же?) и при этом следите за качеством платформы для всех пользователей. Если у вас будут на руках те самые несостыковки и какие-то цифры, которые покажут потенциал последствия от кастома - покажите их, хоть они тут и не главные.
5. Приготовиться к давлению. Если важный клиент настойчив, то он может в каком-то виде начать давить на вас (в корпорациях это могут делать тонко). Кмк, тут важно сохранить фокус на будущем сотрудничестве и не допустить, чтобы этот конфликт стал деструктивным. Это непросто.
А вообще, работа в платформах это довольно специфичная история. Надо будет об этом еще написать что ли...
💯7🔥5❤1
Про сон
Фундаментом здоровой продуктивности (в смысле без веществ) является нормальный сон. Если спишь хорошо - это даёт базу, на которой можно уже строить другие дела. Если спишь плохо - все техники продуктивности мира будут иметь минимальный эффект.
Меня этот факт удивляет своей простотой и действенностью. Каждый раз в нем убеждаюсь, когда плохо посплю пару дней.
Не знаю как у вас, а я периодически не могу быстро заснуть - мысли о проектах и бизнес-идеи, которые сделают меня богачом, сменяют одна другую. В такие моменты использую хак: говорю себе, что я обо в чем этом обязательно подумаю, но попозже; а сейчас я просто уставший человек, которому нужен отдых. И после этого почему-то отпускает.
Ну ладно, я пошел спать, всем спокойной ночи)
Фундаментом здоровой продуктивности (в смысле без веществ) является нормальный сон. Если спишь хорошо - это даёт базу, на которой можно уже строить другие дела. Если спишь плохо - все техники продуктивности мира будут иметь минимальный эффект.
Меня этот факт удивляет своей простотой и действенностью. Каждый раз в нем убеждаюсь, когда плохо посплю пару дней.
Не знаю как у вас, а я периодически не могу быстро заснуть - мысли о проектах и бизнес-идеи, которые сделают меня богачом, сменяют одна другую. В такие моменты использую хак: говорю себе, что я обо в чем этом обязательно подумаю, но попозже; а сейчас я просто уставший человек, которому нужен отдых. И после этого почему-то отпускает.
Ну ладно, я пошел спать, всем спокойной ночи)
❤18👍3
Сказки технического менеджера
Про кастомные доработки в платформах Одним из вызовов при разработке инженерных платформ в больших компаниях является тема кастомных доработок. У вас есть платформа, которой пользуются десятки или сотни команд. И сценарий обычно один и тот же - приходит большой…
Еще немного про платформы
Продолжая тему корпоративных платформ, захотел рассказать, что это такое и чем платформы отличаются от обычных систем и продуктов.
Платформа - это такая ИТ-система, которая решает комплексные задачи, решения которых в свою очередь важны другим системам для предоставления ценности конечному пользователю. По-простому, это такая система, которая дает некий функциональный фундамент, используя который другие системы могут сделать что-то, что даст ценность уже конечному клиенту. А клиент за нее заплатит.
Например, CI-платформа внутри компании никак не приносит денег и ценности клиентам напрямую (они даже не знают, что это такое, а главное зачем), но благодаря ей разработчики могут собирать свои приложения, строить автоматизацию и не ломать себе мозг лишний раз. Это ускоряет их работу, что, в свою очередь, позволяет больше времени уделить разработке продукта для милого клиента. Получается, что CI-платформа предоставляет какой-то кирпичик, который встраивается в технологический фундамент вообще других систем.
Как правило, платформы вырастают из потребности оптимизировать когнитивные, временные и, в конечном итоге, финансовые затраты компании на какие-то общие технические задачи, которые важны широкому кругу корпоративных систем. Чтобы каждый раз при разработке новой системы не решать одни и те же задачи, предлагается делать платформы, которые решат эти задачи за всех разом.
Например, многим системам нужна ролевая модель и управление доступами - го сделаем IAM-платформу (Identity and Access Management), чтобы каждый не изобретал свой велосипед. Или многим системам нужен качественный мониторинг - го сделаем платформу наблюдаемости, чтобы к ней легко подключались и не ломали голову над своими мониторингами каждый раз. Или нам нужно каждый раз поддерживать мультиязычность в UI в наших продуктах - го уже сделаем платформу локализации и будем управлять текстами централизованно. В общем, принцип вы поняли.
Важной чертой платформы является простота и скорость интеграции с ней. Это когда каждый новый продукт может просто и без доработок в платформе интегрироваться с ней, и начать получать ценность. Это становится возможным, когда платформа задает общие стандарты и контракты - вот тебе общий API, вот тебе хорошие гайды, вот тебе лучшие практики. Команда продукта делает все как написано и, вуаля, начинает получать ценность от платформы!
Конечно, я описываю утрированно идеальный случай - на деле в платформе могут быть какие-то неочевидности, гайды могут терять актуальность и т.д. Но для команды, которая делает конечных продукт, преодолеть эти шероховатности в 100 раз проще, чем самим решать изначальную задачу (например, получить норм мониторинг). И вот мера того, как легко и просто интегрироваться (условный time-to-value), это одна из качественных характеристик платформы.
Продолжая тему корпоративных платформ, захотел рассказать, что это такое и чем платформы отличаются от обычных систем и продуктов.
Платформа - это такая ИТ-система, которая решает комплексные задачи, решения которых в свою очередь важны другим системам для предоставления ценности конечному пользователю. По-простому, это такая система, которая дает некий функциональный фундамент, используя который другие системы могут сделать что-то, что даст ценность уже конечному клиенту. А клиент за нее заплатит.
Например, CI-платформа внутри компании никак не приносит денег и ценности клиентам напрямую (они даже не знают, что это такое, а главное зачем), но благодаря ей разработчики могут собирать свои приложения, строить автоматизацию и не ломать себе мозг лишний раз. Это ускоряет их работу, что, в свою очередь, позволяет больше времени уделить разработке продукта для милого клиента. Получается, что CI-платформа предоставляет какой-то кирпичик, который встраивается в технологический фундамент вообще других систем.
Как правило, платформы вырастают из потребности оптимизировать когнитивные, временные и, в конечном итоге, финансовые затраты компании на какие-то общие технические задачи, которые важны широкому кругу корпоративных систем. Чтобы каждый раз при разработке новой системы не решать одни и те же задачи, предлагается делать платформы, которые решат эти задачи за всех разом.
Например, многим системам нужна ролевая модель и управление доступами - го сделаем IAM-платформу (Identity and Access Management), чтобы каждый не изобретал свой велосипед. Или многим системам нужен качественный мониторинг - го сделаем платформу наблюдаемости, чтобы к ней легко подключались и не ломали голову над своими мониторингами каждый раз. Или нам нужно каждый раз поддерживать мультиязычность в UI в наших продуктах - го уже сделаем платформу локализации и будем управлять текстами централизованно. В общем, принцип вы поняли.
Важной чертой платформы является простота и скорость интеграции с ней. Это когда каждый новый продукт может просто и без доработок в платформе интегрироваться с ней, и начать получать ценность. Это становится возможным, когда платформа задает общие стандарты и контракты - вот тебе общий API, вот тебе хорошие гайды, вот тебе лучшие практики. Команда продукта делает все как написано и, вуаля, начинает получать ценность от платформы!
Конечно, я описываю утрированно идеальный случай - на деле в платформе могут быть какие-то неочевидности, гайды могут терять актуальность и т.д. Но для команды, которая делает конечных продукт, преодолеть эти шероховатности в 100 раз проще, чем самим решать изначальную задачу (например, получить норм мониторинг). И вот мера того, как легко и просто интегрироваться (условный time-to-value), это одна из качественных характеристик платформы.
🔥11❤2👍1
Сказки технического менеджера
Еще немного про платформы Продолжая тему корпоративных платформ, захотел рассказать, что это такое и чем платформы отличаются от обычных систем и продуктов. Платформа - это такая ИТ-система, которая решает комплексные задачи, решения которых в свою очередь…
Про трагедию общин
Кстати, одной из предпосылок появления ИТ-платформ является существование такого явления, как трагедия общих ресурсов или, как его еще называют, трагедия общин (tragedy of the commons). Этот термин пришел из экономики, где так назвали ситуацию, когда каждый человек или группа, действуя в своих личных интересах и используя какой-то общий ресурс, в итоге истощает его настолько, что в проигрыше остаются все.
Классический пример это темка с пастбищем. Сельская община имеет общее пастбище, на котором каждый может пасти свой скот бесплатно. Каждый фермер думает: "Если я прикуплю еще одну буренку, мой доход вырастет". Увеличение на одну корову почти не вредит пастбищу, но когда все фермеры так рассуждают и увеличивают стада, трава не успевает восстанавливаться. В итоге пастбище истощается, скот начинает голодать, и все остаются в проигрыше. Вот такое явление.
В ИТ такое тоже происходит. Например, быстродействие мобильного приложения - это важная штука, которая влияет на опыт клиента. Однако ради того, чтобы выпускать фичи быстрее, разработчики могут костылить (не без влияния менеджеров), что в итоге влияет на производительность аппки. Если такое сделали разок-другой - не страшно. Но если приложение делают несколько команд и каждая чуть-чуть его замедлит своим костылем - происходит трагидия общин. Перфоманс драматически падает, как и желание клиентов пользоваться этимну вы поняли . Одним из решений может являться выделение платформенной команды, которая будет сфокусирована на теме перфоманса - создавать инструменты для измерения и оптимизаций, помогать другим командам и выстраивать техно диктатуру и т.д.
Еще один пример - это уведомления клиентам в виде пушей, email и т.д. Толерантность клиента к этим уведомлениям это как бы общий ограниченный ресурс. Если каждая команда будет фигачить пуши только ради увеличения собственных метрик, в итоге клиент задолбается получать по 5 пушей в день от маркетинга про супер акции, привлечение про новые продукты, технической команды о новых фичах, от комплаенса о документах и т.д. В моменте у каждой из этих команд могут вырасти целевые метрики, но через время клиенты просто отключат эти уведомления нафиг, и мы потеряем целый канал коммуникации. Одним из решений может являться выделение платформы уведомлений, в которой помимо прочего будут закреплены контактные политики, которые не позволят заспамить клиента больше положенного. Даже если продакту Васе очень надо нагнать трафик на свой экран.
В общем, платформы возникают там, где нужно следить за общим ресурсом, который важен многим в компании и истощение которого явно повредит бизнесу.
Кстати, одной из предпосылок появления ИТ-платформ является существование такого явления, как трагедия общих ресурсов или, как его еще называют, трагедия общин (tragedy of the commons). Этот термин пришел из экономики, где так назвали ситуацию, когда каждый человек или группа, действуя в своих личных интересах и используя какой-то общий ресурс, в итоге истощает его настолько, что в проигрыше остаются все.
Классический пример это темка с пастбищем. Сельская община имеет общее пастбище, на котором каждый может пасти свой скот бесплатно. Каждый фермер думает: "Если я прикуплю еще одну буренку, мой доход вырастет". Увеличение на одну корову почти не вредит пастбищу, но когда все фермеры так рассуждают и увеличивают стада, трава не успевает восстанавливаться. В итоге пастбище истощается, скот начинает голодать, и все остаются в проигрыше. Вот такое явление.
В ИТ такое тоже происходит. Например, быстродействие мобильного приложения - это важная штука, которая влияет на опыт клиента. Однако ради того, чтобы выпускать фичи быстрее, разработчики могут костылить (не без влияния менеджеров), что в итоге влияет на производительность аппки. Если такое сделали разок-другой - не страшно. Но если приложение делают несколько команд и каждая чуть-чуть его замедлит своим костылем - происходит трагидия общин. Перфоманс драматически падает, как и желание клиентов пользоваться этим
Еще один пример - это уведомления клиентам в виде пушей, email и т.д. Толерантность клиента к этим уведомлениям это как бы общий ограниченный ресурс. Если каждая команда будет фигачить пуши только ради увеличения собственных метрик, в итоге клиент задолбается получать по 5 пушей в день от маркетинга про супер акции, привлечение про новые продукты, технической команды о новых фичах, от комплаенса о документах и т.д. В моменте у каждой из этих команд могут вырасти целевые метрики, но через время клиенты просто отключат эти уведомления нафиг, и мы потеряем целый канал коммуникации. Одним из решений может являться выделение платформы уведомлений, в которой помимо прочего будут закреплены контактные политики, которые не позволят заспамить клиента больше положенного. Даже если продакту Васе очень надо нагнать трафик на свой экран.
В общем, платформы возникают там, где нужно следить за общим ресурсом, который важен многим в компании и истощение которого явно повредит бизнесу.
🔥8❤2💯1
Ладно, а теперь к действительно важным вопросам. Существенную часть моего рабочего времени занимают созвоны. Видел по коллегам в офисе, что я не одинок в этом.
Кто-то спокойно участвует во всех звонках прямо из общего опенспейса, его не сильно парит, что окружающие вынуждены его слушать. Кому-то он этим мешает, а кому-то нет. А кто-то созванивается только в переговорках, парится с их бронью, но зато не создаёт шум в рабочем пространстве.
Какой подход вам ближе? И как вы относитесь к тем, кто болтает на звонках прямо в опенспейсе?
Мое мнение:
Когда я работал разработчиком, меня бесило, что менеджеры целый день трындят на звонках в опенспейсе и из-за них я не могу нормально сконцентрироваться.
Теперь я сам превратился в менеджера, но те эмоции хорошо помню. Поэтому всегда стараюсь уходить в переговорки и не шуметь в общем рабочем пространстве, чтобы не мешать коллегам удерживать хрустальные замки в голове. Но искать свободные переговорки это боль(
Кто-то спокойно участвует во всех звонках прямо из общего опенспейса, его не сильно парит, что окружающие вынуждены его слушать. Кому-то он этим мешает, а кому-то нет. А кто-то созванивается только в переговорках, парится с их бронью, но зато не создаёт шум в рабочем пространстве.
Какой подход вам ближе? И как вы относитесь к тем, кто болтает на звонках прямо в опенспейсе?
Мое мнение:
Теперь я сам превратился в менеджера, но те эмоции хорошо помню. Поэтому всегда стараюсь уходить в переговорки и не шуметь в общем рабочем пространстве, чтобы не мешать коллегам удерживать хрустальные замки в голове. Но искать свободные переговорки это боль(
❤4👍1
Мини-разбор крупного сбоя AWS: как гонка потоков в DNS обрушила половину интернета. Часть 1
На днях Amazon выкатили что-то типа постмортема по нашумевшему сбою 19-20 октября в регионе
Что там было.
Часть 1: Падение DynamoDB
Коревая причина - скрытый баг в виде гонки состояний (race condition) в системе управления DNS сервиса DynamoDB (NoSQL БД). Для управления тьмой DNS записей (пишут, что записей сотни тысяч, охотно верю), у ребят был написан собственный сервис автоматизации управления. В нём два компонента:
- DNS Planner. Как я понял, это штука, которая мониторит состояние входных балансировщиков DynamoDB и менеджерит все DNS записи в регионе. Это единая точка управления, которая позволяет менять DNSы сразу по огромной инфре DynamoDB. Ребята пишут, что недавно они не без помощи этой системы смогли внедрить IPv6 эндоинты - кто забыл, для IPv6 нужны записи типа AAAA (я не ору, это тип записей так называется), запустить такую фичу на их масштабах просто невозможно без подобной системы.
- DNS Enactor. Это система типа рук DNS Planner'а. Планер планирует, а Enactor фактически выполняет сформированный план. Для отказоустойчивости (хе хе) Enactor'ов три штуки в разных зонах доступности. Они мониторят появление новых планов и транзакционно их применяют. Поэтому если один Enactor сломался, другие все равно все сделают.
Что именно пошло не так, следите за руками:
1. Медленный Enactor. Первый Enactor'ов взял план в работу и чуть завис, пытаясь применить DNS-план. Пишут, что такое обычно не случается и все работает быстро, ага. В самом начале своей работы Enactor чекает, что у него в работе ДЕЙСТВИТЕЛЬНО новейший DNS-план. Делает он это через походы в несколько эндпоинтов, и вот в этот раз он тут задержался. Скорее всего, какие-то их них отвечали дольше обычного, он делал ретраи, но в целом, в этот момент задержка была значительно дольше обычного.
2. Быстрый и везучий Enactor. Пока первый Enactor тормозил, Planner успел создал несколько новых планов, новейший из которых подхватил второй Enactor и успешно применил. Тут ему повезло, он не словил таких задержек, как словил первый.
3. Очистка прошлых планов. В конце своей работы быстрый Enactor, как и обычно, запустил очистку старых планов (они не нужны, он ведь уже применил новейший), и потер план, который был уже в работе у первого Enactor'а.
4. Неконсистентое состояние. Тут «зависший» Enactor наконец-то отмирает и идет выполнять свой очень старый план. Напомню, он уже типа успешно проверил, что у него самая актуальная версия плана. Судя по всему, за деталями плана он идет в БД, а там плана уже нет. И он выставляет пустые DNS по всем управляемым записям.
В итоге куча DNS записей DynamoDB оказались пустыми. Никто не может к ним подключиться и дальше начинается эффект домино, о котором напишу в следующей части.
На днях Amazon выкатили что-то типа постмортема по нашумевшему сбою 19-20 октября в регионе
us-east-1 — одном из их самых важных регионов всего AWS. Напомню, тогда тысячи сервисов по всему миру, включая Reddit, The Washington Post и Perplexity, были недоступны или работали с перебоями. Масштаб был колоссальный. Нам в РФ немного "повезло", как и прошлогоднем сбое в Windows и Crowdstrike, о котором я писал раньше - у нас AWS заблокирован, поэтому бизнес там ничего не хостил.Что там было.
Часть 1: Падение DynamoDB
Коревая причина - скрытый баг в виде гонки состояний (race condition) в системе управления DNS сервиса DynamoDB (NoSQL БД). Для управления тьмой DNS записей (пишут, что записей сотни тысяч, охотно верю), у ребят был написан собственный сервис автоматизации управления. В нём два компонента:
- DNS Planner. Как я понял, это штука, которая мониторит состояние входных балансировщиков DynamoDB и менеджерит все DNS записи в регионе. Это единая точка управления, которая позволяет менять DNSы сразу по огромной инфре DynamoDB. Ребята пишут, что недавно они не без помощи этой системы смогли внедрить IPv6 эндоинты - кто забыл, для IPv6 нужны записи типа AAAA (я не ору, это тип записей так называется), запустить такую фичу на их масштабах просто невозможно без подобной системы.
- DNS Enactor. Это система типа рук DNS Planner'а. Планер планирует, а Enactor фактически выполняет сформированный план. Для отказоустойчивости (хе хе) Enactor'ов три штуки в разных зонах доступности. Они мониторят появление новых планов и транзакционно их применяют. Поэтому если один Enactor сломался, другие все равно все сделают.
Что именно пошло не так, следите за руками:
1. Медленный Enactor. Первый Enactor'ов взял план в работу и чуть завис, пытаясь применить DNS-план. Пишут, что такое обычно не случается и все работает быстро, ага. В самом начале своей работы Enactor чекает, что у него в работе ДЕЙСТВИТЕЛЬНО новейший DNS-план. Делает он это через походы в несколько эндпоинтов, и вот в этот раз он тут задержался. Скорее всего, какие-то их них отвечали дольше обычного, он делал ретраи, но в целом, в этот момент задержка была значительно дольше обычного.
2. Быстрый и везучий Enactor. Пока первый Enactor тормозил, Planner успел создал несколько новых планов, новейший из которых подхватил второй Enactor и успешно применил. Тут ему повезло, он не словил таких задержек, как словил первый.
3. Очистка прошлых планов. В конце своей работы быстрый Enactor, как и обычно, запустил очистку старых планов (они не нужны, он ведь уже применил новейший), и потер план, который был уже в работе у первого Enactor'а.
4. Неконсистентое состояние. Тут «зависший» Enactor наконец-то отмирает и идет выполнять свой очень старый план. Напомню, он уже типа успешно проверил, что у него самая актуальная версия плана. Судя по всему, за деталями плана он идет в БД, а там плана уже нет. И он выставляет пустые DNS по всем управляемым записям.
В итоге куча DNS записей DynamoDB оказались пустыми. Никто не может к ним подключиться и дальше начинается эффект домино, о котором напишу в следующей части.
🔥11❤3
Мини-разбор крупного сбоя AWS: как гонка потоков в DNS обрушила пол-интернета. Часть 2
В прошлой части я начал разбирать постмортем сбоя в AWS, в этом продолжу.
Часть 2: Эффект домино
Тут-то и началось самое интересное. Оказалось, что DynamoDB это фундамент для многих других сервисов AWS, и его отказ запустил цепную реакцию:
- EC2 (виртуальные серверы): для начала, какое-то время совсем не работало создание новых ВМ. Как пишут, DynamoDB использовалось в Control Plane системе, которая управляла железными кластерами, на которых крутились ВМ. Для синхронизации состояния (например, перезагрузка, запуск новой ВМ и т.д.) использовалась логика, которая хранила данные в сервисной БД. Базы больше нет, синки не происходит и, как следствие, в Control Plane накопилась дикая очередь задач на синхронизацию. Примечательно, что очередь в какой-то момент начала расти лавинообразно: сервер не создавался за заданный таймаут, поэтому система ставила новую задачу в очередь на создание, и т.д.
- EC2 (опять): когда это разглебли, то оказалось, что новые ВМки создаются, но не становятся доступными по сети. Тачку создал, а достучаться до нее никто не может. После создания ВМ на нее нужно задеплоить сетевую конфигурацию и контроллер, который отвечает за эту работу, не был готов к такой нагрузке, которая на него обрушилась после нескольких часов простоя. Инженерам AWS пришлось сильно ограничивать очередь, чтобы воркеры обрабатывали записи и не "захлебывались". Пока они этим занимались, цепная реакция продолжалась.
- NLB (балансировщик нагрузки): новые ВМки попадали в конфиги балансировщиков КУЧИ разных сервисов, но мы помним, что многие из них все еще недоступны по сети. Это привело к очень интересной ситуации. Для health check'ов была своя собственная подсистема - это логично, на таких масштабах health check'и это так еще задача. Из-за того, что неадекватно много нод EC2 были недоступны и не проходили проверку на health check, система этих самых health check'ов автоматически масштабировалась под рост нагрузки. И самое прикольное, что для этого она создавала серверы из...EC2!
Таким образом, уже в работе самой подсистемы health check'ов были недоступные ВМки. Это приводило к тому, что часть задач health check'ов распределялись и на них и помечались FAILED, хотя вполне возможно, что целевой сервис был жив и здоров.
Ситуацию осложняло то, что из-за таких "флапающих" проверок - то сервис доступен, то недоступен, смотря какая нода будет делать health check - срабатывала другая автоматика, которая выполняла всякие failover операции. Это приводило к другим каскадным изменениям в системах🫠
- Из-за проблем на таком фундаментальном и платформенном уровне, страдать каскадно начали вообще все сервисы AWS. Из "прикольного" отмечу разве что IAM (система аутентификации и авторизации) - пока она лежала, никто не мог никуда залогиниться, а чтобы оживить сервисы надо было что-то сделать, а для этого надо залогиниться:)
Сбой длился примерно 15 часов. В интернетах пишут о разных выводах, которые люди сделали для себя - кто-то о важности multi-cloud, чтобы не зависеть от одного провайдера, кто-то о важности настроенных процессов инцидент-менеджмента и ранбуков в командах, кто-то о хрупкости всех этих гигантских систем и том, что ИИ нас тут спасет.
Я тоже сделал некоторые выводы, о них напишу в следующей части.
В прошлой части я начал разбирать постмортем сбоя в AWS, в этом продолжу.
Часть 2: Эффект домино
Тут-то и началось самое интересное. Оказалось, что DynamoDB это фундамент для многих других сервисов AWS, и его отказ запустил цепную реакцию:
- EC2 (виртуальные серверы): для начала, какое-то время совсем не работало создание новых ВМ. Как пишут, DynamoDB использовалось в Control Plane системе, которая управляла железными кластерами, на которых крутились ВМ. Для синхронизации состояния (например, перезагрузка, запуск новой ВМ и т.д.) использовалась логика, которая хранила данные в сервисной БД. Базы больше нет, синки не происходит и, как следствие, в Control Plane накопилась дикая очередь задач на синхронизацию. Примечательно, что очередь в какой-то момент начала расти лавинообразно: сервер не создавался за заданный таймаут, поэтому система ставила новую задачу в очередь на создание, и т.д.
- EC2 (опять): когда это разглебли, то оказалось, что новые ВМки создаются, но не становятся доступными по сети. Тачку создал, а достучаться до нее никто не может. После создания ВМ на нее нужно задеплоить сетевую конфигурацию и контроллер, который отвечает за эту работу, не был готов к такой нагрузке, которая на него обрушилась после нескольких часов простоя. Инженерам AWS пришлось сильно ограничивать очередь, чтобы воркеры обрабатывали записи и не "захлебывались". Пока они этим занимались, цепная реакция продолжалась.
- NLB (балансировщик нагрузки): новые ВМки попадали в конфиги балансировщиков КУЧИ разных сервисов, но мы помним, что многие из них все еще недоступны по сети. Это привело к очень интересной ситуации. Для health check'ов была своя собственная подсистема - это логично, на таких масштабах health check'и это так еще задача. Из-за того, что неадекватно много нод EC2 были недоступны и не проходили проверку на health check, система этих самых health check'ов автоматически масштабировалась под рост нагрузки. И самое прикольное, что для этого она создавала серверы из...EC2!
Таким образом, уже в работе самой подсистемы health check'ов были недоступные ВМки. Это приводило к тому, что часть задач health check'ов распределялись и на них и помечались FAILED, хотя вполне возможно, что целевой сервис был жив и здоров.
Ситуацию осложняло то, что из-за таких "флапающих" проверок - то сервис доступен, то недоступен, смотря какая нода будет делать health check - срабатывала другая автоматика, которая выполняла всякие failover операции. Это приводило к другим каскадным изменениям в системах🫠
- Из-за проблем на таком фундаментальном и платформенном уровне, страдать каскадно начали вообще все сервисы AWS. Из "прикольного" отмечу разве что IAM (система аутентификации и авторизации) - пока она лежала, никто не мог никуда залогиниться, а чтобы оживить сервисы надо было что-то сделать, а для этого надо залогиниться:)
Сбой длился примерно 15 часов. В интернетах пишут о разных выводах, которые люди сделали для себя - кто-то о важности multi-cloud, чтобы не зависеть от одного провайдера, кто-то о важности настроенных процессов инцидент-менеджмента и ранбуков в командах, кто-то о хрупкости всех этих гигантских систем и том, что ИИ нас тут спасет.
Я тоже сделал некоторые выводы, о них напишу в следующей части.
👍7
- "Я менеджер, а не разработчик, зачем мне лезть в такие технические дебри?"
- "Ой, это архитектурный вопрос, у меня для этого есть сеньоры, пусть они разбираются"
В разное время ловил такое настроение при обсуждении архитектурных вопросов как у коллег TPM-ов, так и у себя лично. Но что меня всегда отрезвляло и возвращало внимание на такие вопросы, так это понимание, что архитектурные дела сильно влияют на продукт - как на его функциональные возможности и потенциал, так и на нефункциональные особенности - надежность, быстродействие, стоимость владения и т.д. И иногда пару хороших нетехнических вопросов к свежему RFC могут сильно повлиять на итоговое решение - "ой, а что это тоже важно клиентам?". Конечно, в супер зрелых командах все такие вещи берут на себя супер зрелые тимлиды, архитекторы и вот такие ребята, но в реальности граней может быть намного больше:)
И я тут не говорю, что технический менеджер обязан быть архитектором - нет, это, как правило, отдельные люди с особым складом ума, большим опытом и глубокими техническими навыками. Но понимать базовые темы в архитектуре ПО считаю менеджеру необходимым еще и потому, что оно помогает в общении с инженерами. Когда они говорят про eventual consistency, паттерн "сага" или хореографию, а вы думаете причем тут танцы — это чувствуется. Команде приходится упрощать объяснения, переводить технические нюансы на "менеджерский язык". Именно в этот момент неизбежно где-то пропадут важные детали, которые в итоге могут серьезно повлиять на пользовательский опыт или стоимость разработки.
Как техническому менеджеру прокачивать навык архитектуры?
1. Пилить свои pet-проекты
Мало что может заменить реальную практику построения систем. И если в рабочей обстановке есть жесткие ограничения, то написать свой микро-продукт, развернуть его и попытаться его запустить на пользователей - это доступно почти каждому. За это время вв гарантированно узнаете много нового не только с технической стороны, но и с продуктовой.
Правда, я тут чуть лукавлю т.к. в pet-проектах обычно нет большой нагрузки, а именно она является главным катализатором сложных архитектурных решений.
2. Читать, смотреть, слушать
Тут никакого инсайта - читать книжки ("кабанчика", например), смотреть выступления, сидеть с блокнотиком вечером и анализировать разные концепты. Конечно, сейчас все это можно значительно ускорить, если вы будете общаться с ChatGPT и подобными ребятами, но из-за их галлюцинаций есть риск того, что вас введут в заблуждение. Зато намного меньше рисков, если ходить на вебинары к опытным людям.
Кстати, 18 ноября в 12:00 будет один такой - "Архитектурные стили и паттерны ПО" от компании ЛИИС (Лаборатория Интеллектуальных Инженерных Систем).
Там расскажут:
- Что такое Clean Architecture на практике,
- Как выбрать свой архитектурный стиль (и не пожалеть об этом).
- Монолит, модульный монолит, EDA, SOA, MSA Onion, Hexagonal, Pipes & Filters и чем они все отличаются, кроме названий из Википедии
Подходит для техлидов, тимлидов, разработчиков и аналитиков, у которых болит от архитектуры — и тех, кто просто хочет понять, почему она вообще болит.
Участие бесплатное, а зарегистрироваться можно по ссылке.
liis.timepad.ru
Архитектурные стили и паттерны ПО / События на TimePad.ru
Рассмотрим архитектурную парадигму "Clean Architecture", обсудим распространненые антипаттерны в некоторых архитектурных стилях, и порассуждаем, чем нужно руководствоваться при выборе архитектурного стиля.
❤6👍5🔥2
Готовлюсь сейчас к закрытому выступлению на большую аудиторию - более 2 тыс. человек. Нюанс в том, что на доклад у меня будет буквально 5 минут и еще пару минут на ответы на вопросы. Задержаться нельзя.
И вот, казалось бы, всего 5 минут, а подготовить такой доклад немногим проще, чем получасовой. Плотность информации на единицу времени намного больше, а потерять 30 сек. на какое-нибудь отвлечение мысли - непозволительная роскошь. В большом докладе даже если сбился, то через минуту можно вырулить на нужную ветку повествования и все норм, а в таком коротком - это почти катастрофа. С другой стороны, когда выступаешь на такое кол-во людей, по-другому быть и не может - все выступления должны быть хорошо подготовленными и без лишней воды т.к. компании дорого обходятся такие встречи.
Со временем при подготовке докладов у меня выработались некоторые принципы и наблюдения по тому, как сделать доклад получше.
Поделюсь парочкой из них:
1. Люди больше любят слушать про себя, чем про вас
Конечно, любознательным людям бывает интересно просто послушать чужой опыт в формате JFYI (особенно, если форма доклада хороша). Но большая часть людей ищет в докладе инфу, которая не просто интересна, а прежде всего полезна в их собственных задачах. Они вовлекаются, когда слышат про свои проблемы, про свои вопросы, про свои перспективы - когда вы говорите о них. Поэтому в своих докладах я стараюсь вставлять "крючки", которые дают целевой аудитории ассоциировать мой доклад с собой.
2. Доклад нужно хорошенько отрепетировать
И речь тут не о том, чтобы заучить его дословно, а о том, что нужно уверенно ориентироваться в докладе, думать на пару слайдов вперед, чтобы к каждой последующей мысли проговаривать логичные и продуманные переходы. Это невозможно сделать, если не прогонять доклад с презентацией и не репетировать его вслух. По ходу подготовки я часто в мыслях прогоняю разные его кусочки, думаю, какие смыслы вложить и как их лучше сформулировать. Но много раз бывало так, что те обороты, которые в голове звучат круто, ощущаются тупо/сухо/неуместно, когда проговариваешь их вслух.
3. Переходы - очень важная часть
Когда спикер скачет с мысли на мысль, это заставляет слушателей напрягаться, чтобы удержать внимание и нить повествования. Не все слушатели смогут сделать это и будут отваливаться. Переходы - это как смазка между шестернями идей вашего доклада. Если переходы продуманы, если они предвосхищают вопросы слушателя, если они за ручку проводят его от одной идеи к другой, то такой доклад ощущается более цельным. Поэтому в своих докладах я прямо дословно прописываю переходы и уделяю время их придумыванию.
4. Любой публичный доклад - это миниатюрное шоу
Спикер стоит на виду и внимание людей устремлено на него. Они следят за его лицом, телом и интонацией. Они молчат, позволяя ему говорить и задавать тон. Все элементы шоу на месте, так почему бы не относиться к этому как к небольшому шоу? Конечно, не всегда это уместно, но если формат мероприятия позволяет, мне нравится играть с этим - особая интонация в кульминации, резкое изменение ритма речи, инсценировка какой-то ситуации и подобное.
И вот, казалось бы, всего 5 минут, а подготовить такой доклад немногим проще, чем получасовой. Плотность информации на единицу времени намного больше, а потерять 30 сек. на какое-нибудь отвлечение мысли - непозволительная роскошь. В большом докладе даже если сбился, то через минуту можно вырулить на нужную ветку повествования и все норм, а в таком коротком - это почти катастрофа. С другой стороны, когда выступаешь на такое кол-во людей, по-другому быть и не может - все выступления должны быть хорошо подготовленными и без лишней воды т.к. компании дорого обходятся такие встречи.
Со временем при подготовке докладов у меня выработались некоторые принципы и наблюдения по тому, как сделать доклад получше.
Поделюсь парочкой из них:
1. Люди больше любят слушать про себя, чем про вас
Конечно, любознательным людям бывает интересно просто послушать чужой опыт в формате JFYI (особенно, если форма доклада хороша). Но большая часть людей ищет в докладе инфу, которая не просто интересна, а прежде всего полезна в их собственных задачах. Они вовлекаются, когда слышат про свои проблемы, про свои вопросы, про свои перспективы - когда вы говорите о них. Поэтому в своих докладах я стараюсь вставлять "крючки", которые дают целевой аудитории ассоциировать мой доклад с собой.
2. Доклад нужно хорошенько отрепетировать
И речь тут не о том, чтобы заучить его дословно, а о том, что нужно уверенно ориентироваться в докладе, думать на пару слайдов вперед, чтобы к каждой последующей мысли проговаривать логичные и продуманные переходы. Это невозможно сделать, если не прогонять доклад с презентацией и не репетировать его вслух. По ходу подготовки я часто в мыслях прогоняю разные его кусочки, думаю, какие смыслы вложить и как их лучше сформулировать. Но много раз бывало так, что те обороты, которые в голове звучат круто, ощущаются тупо/сухо/неуместно, когда проговариваешь их вслух.
3. Переходы - очень важная часть
Когда спикер скачет с мысли на мысль, это заставляет слушателей напрягаться, чтобы удержать внимание и нить повествования. Не все слушатели смогут сделать это и будут отваливаться. Переходы - это как смазка между шестернями идей вашего доклада. Если переходы продуманы, если они предвосхищают вопросы слушателя, если они за ручку проводят его от одной идеи к другой, то такой доклад ощущается более цельным. Поэтому в своих докладах я прямо дословно прописываю переходы и уделяю время их придумыванию.
4. Любой публичный доклад - это миниатюрное шоу
Спикер стоит на виду и внимание людей устремлено на него. Они следят за его лицом, телом и интонацией. Они молчат, позволяя ему говорить и задавать тон. Все элементы шоу на месте, так почему бы не относиться к этому как к небольшому шоу? Конечно, не всегда это уместно, но если формат мероприятия позволяет, мне нравится играть с этим - особая интонация в кульминации, резкое изменение ритма речи, инсценировка какой-то ситуации и подобное.
👍11🔥8❤3💯1
Вчера прошла моя первая встреча с подписчиками. Вернее будет сказать с подписчиком. Хотя...я тоже на него подписан, выходит, для него это тоже встреча с подписчиком? Короче, простите, я просто очень хотел пошутить на эту тему:)
За Ильей я наблюдаю давно: слушал его подкаст Айти Самурай, читаю его тг-канал, где он пишет интересное про технический и "обычный" менеджмент. Пару раз мы даже кратко переписывались.
Илья вообще довольно опытный и разносторонний человек - сменил несколько стран, долгое время жил в Штатах, работал продактом в Google и Amazon, запускал свой стартап, а сейчас он CPO API Яндекс Карт, это если говорить о внешних регалиях.
Мне было интересно увидеться вживую, и вдвойне приятно, когда такие встречи проходят тепло и ненапряжно. Бывают встречи, когда ты рад, что они закончились, а бывают такие, которые хочется продлить еще и еще - вот эта была как раз явно из второй группы.
За Ильей я наблюдаю давно: слушал его подкаст Айти Самурай, читаю его тг-канал, где он пишет интересное про технический и "обычный" менеджмент. Пару раз мы даже кратко переписывались.
Илья вообще довольно опытный и разносторонний человек - сменил несколько стран, долгое время жил в Штатах, работал продактом в Google и Amazon, запускал свой стартап, а сейчас он CPO API Яндекс Карт, это если говорить о внешних регалиях.
Мне было интересно увидеться вживую, и вдвойне приятно, когда такие встречи проходят тепло и ненапряжно. Бывают встречи, когда ты рад, что они закончились, а бывают такие, которые хочется продлить еще и еще - вот эта была как раз явно из второй группы.
🔥18❤7
Про догфудинг
Да, если вы не слышали этот термин раньше, то выглядит он дико. Интернеты говорят, что в ИТ это определение впервые в 1988 году использовал менеджер компании Microsoft Пол Мариц, когда отправил коллеге, менеджеру по тестированию Microsoft LAN Manager (который уже канул в Лету - я не про коллегу, а про продукт), письмо с заголовком «Eating our own dog food», призывая увеличить использование собственного продукта внутри компании. Как бы там ни было на самом деле, сейчас этот термин используется в том смысле, что сотрудникам компании предлагается использовать собственный продукт как и их клиентам, в тех же условиях и в том же виде. Мол, "попользуйтесь тем, что сами создали. Ну как, нравится?".
А причём тут технический менеджмент, спросите вы?
А вот причём. Я искренне убежден, что если технический менеджер не использует свой продукт регулярно как обычный пользователь, то он теряет 80% возможностей для его улучшения. Цифру я, конечно, придумал, но сути это не меняет.
Не используешь свой продукт:
- не видишь очевидных провалов в сценарии использования (кто-то же другой их должен заметить, да?)
- не замечаешь раздражающих багов (которые уже давно есть в беклоге, просто "не горят")
- не примечаешь напрашивающихся улучшений.
Конечно, всё это актуально для продуктов, в которых сам менеджер является целевой аудиторией, для которой делается система. Но что делать, если вы разрабатываете какую-то специфичную историю, например, b2b сервис по автоматизации расчётов коммунальных услуг для складов? Как тут догфудить?
Честно говоря, однозначного ответа я не нашёл. Я вижу в этом границы использования этой практики - если продукт неактуален для меня, как для клиента, то насколько глубокую обратную связь по его использованию я смогу дать? Это как просить водителя автобуса пользоваться штурвалом от самолета.
Однако уверенное базовое понимание ценности системы для пользователей, способность осмысленно пройти основные сценарии использования - всё это минимум, который я бы ожидал от любого технического менеджера.
---
Пост из марта 2024
Да, если вы не слышали этот термин раньше, то выглядит он дико. Интернеты говорят, что в ИТ это определение впервые в 1988 году использовал менеджер компании Microsoft Пол Мариц, когда отправил коллеге, менеджеру по тестированию Microsoft LAN Manager (который уже канул в Лету - я не про коллегу, а про продукт), письмо с заголовком «Eating our own dog food», призывая увеличить использование собственного продукта внутри компании. Как бы там ни было на самом деле, сейчас этот термин используется в том смысле, что сотрудникам компании предлагается использовать собственный продукт как и их клиентам, в тех же условиях и в том же виде. Мол, "попользуйтесь тем, что сами создали. Ну как, нравится?".
А причём тут технический менеджмент, спросите вы?
А вот причём. Я искренне убежден, что если технический менеджер не использует свой продукт регулярно как обычный пользователь, то он теряет 80% возможностей для его улучшения. Цифру я, конечно, придумал, но сути это не меняет.
Не используешь свой продукт:
- не видишь очевидных провалов в сценарии использования (кто-то же другой их должен заметить, да?)
- не замечаешь раздражающих багов (которые уже давно есть в беклоге, просто "не горят")
- не примечаешь напрашивающихся улучшений.
Конечно, всё это актуально для продуктов, в которых сам менеджер является целевой аудиторией, для которой делается система. Но что делать, если вы разрабатываете какую-то специфичную историю, например, b2b сервис по автоматизации расчётов коммунальных услуг для складов? Как тут догфудить?
Честно говоря, однозначного ответа я не нашёл. Я вижу в этом границы использования этой практики - если продукт неактуален для меня, как для клиента, то насколько глубокую обратную связь по его использованию я смогу дать? Это как просить водителя автобуса пользоваться штурвалом от самолета.
Однако уверенное базовое понимание ценности системы для пользователей, способность осмысленно пройти основные сценарии использования - всё это минимум, который я бы ожидал от любого технического менеджера.
---
Пост из марта 2024
👍9❤2
Про продуктовые решения на интуиции
До сих пор не сформировал у себя твердую и четкую позицию относительно решений по фичам/проектам на "чуйке". Это когда у лица, принимающего решения, есть сильное мнение о том, что нужно сделать для дорогих клиентов. Но данных или фактов о том, почему это действительно им нужно, у него нет - только уверенность.
Я видел как продакты генерировали и приоритезировали гипотезы, проводили качественные и количественные исследования. А на выходе получалась посредственная серая ерунда. И видел противоположные примеры - когда "на чуйке" делали такие штуки, которые всем заходили и были полезны пользователям. Наоборот, кстати, тоже видал. Второй подход принято шеймить в продуктовом комьюнити и, конечно, не без оснований.
Но блин.
Иногда ведь это срабатывает. И даже почаще, чем сломаные часы, которые два раза в день показывают правильное время.
Такие люди как будто могут почувствовать такие задачи пользователей, о которых они не говорят в интервью. Или уловить тренды и понять, какие сценарии будут актуальны в ближайшем будущем.
Для себя пока решил слушать таких людей очень внимательно, критически относиться к их предложениям, но при этом считать их мнение весомым аргументом при принятии решений.
А что вы думаете насчет этой продуктовой "чуйки" ? Правда есть такое или просто везение?
До сих пор не сформировал у себя твердую и четкую позицию относительно решений по фичам/проектам на "чуйке". Это когда у лица, принимающего решения, есть сильное мнение о том, что нужно сделать для дорогих клиентов. Но данных или фактов о том, почему это действительно им нужно, у него нет - только уверенность.
Я видел как продакты генерировали и приоритезировали гипотезы, проводили качественные и количественные исследования. А на выходе получалась посредственная серая ерунда. И видел противоположные примеры - когда "на чуйке" делали такие штуки, которые всем заходили и были полезны пользователям. Наоборот, кстати, тоже видал. Второй подход принято шеймить в продуктовом комьюнити и, конечно, не без оснований.
Но блин.
Иногда ведь это срабатывает. И даже почаще, чем сломаные часы, которые два раза в день показывают правильное время.
Такие люди как будто могут почувствовать такие задачи пользователей, о которых они не говорят в интервью. Или уловить тренды и понять, какие сценарии будут актуальны в ближайшем будущем.
Для себя пока решил слушать таких людей очень внимательно, критически относиться к их предложениям, но при этом считать их мнение весомым аргументом при принятии решений.
А что вы думаете насчет этой продуктовой "чуйки" ? Правда есть такое или просто везение?
❤8💯1
Знакомство и розыгрыш книги
UPD: розыгрыш состоялся! Поздравляю @avzarkov!
На мой канал подписано уже больше 400 человек. И это офигеть как много! Кого-то я хорошо знаю, с кем-то где-то пересекался, но с большей частью я никак не знаком. А познакомиться хочется:)
Расскажите, пожалуйста, о себе в комментах - любопытно, какое комьюнити тут получилось:
- Небольшое intro
- Индустрия и продукт, над которым работаете (можно и в общем, если NDA или не хочется называть)
- Ваше личное интересное профессиональное открытие этого года - инструмент, мысль, урок вообще что угодно.
А чтобы было интереснее, среди комментаторов я разыграю каноничную продуктовую книгу Марти Кагана "Вдохновленные" (Inspired) в бумажном формате (отправлю бесплатно Яндекс Доставкой). Победителя выберу 26 декабря (в пятницу) с помощью рандомайзера.
Штош, давайте тогда я начну первым комментом.
UPD: розыгрыш состоялся! Поздравляю @avzarkov!
На мой канал подписано уже больше 400 человек. И это офигеть как много! Кого-то я хорошо знаю, с кем-то где-то пересекался, но с большей частью я никак не знаком. А познакомиться хочется:)
Расскажите, пожалуйста, о себе в комментах - любопытно, какое комьюнити тут получилось:
- Небольшое intro
- Индустрия и продукт, над которым работаете (можно и в общем, если NDA или не хочется называть)
- Ваше личное интересное профессиональное открытие этого года - инструмент, мысль, урок вообще что угодно.
А чтобы было интереснее, среди комментаторов я разыграю каноничную продуктовую книгу Марти Кагана "Вдохновленные" (Inspired) в бумажном формате (отправлю бесплатно Яндекс Доставкой). Победителя выберу 26 декабря (в пятницу) с помощью рандомайзера.
Штош, давайте тогда я начну первым комментом.
❤9
"Моменты неудач не менее важны, чем моменты успеха. То, как мы поступаем и думаем в моменты, когда что-то не получается или мы провалились - во многом определяет, кто мы есть" (с) придумал это прямо, пока писал пост.
Захотелось поделиться с вами парой историй своих карьерных неудач. Вдруг опыт их прохождения подбодрит кого-то.
"Как мне посмеялись в лицо о моей мечте стать программистом, а потом предлагали бонус за работу у них"
Первая история случилась в начале 2010-x годов. Я, будучи студентом первых курсов, собеседовался в компанию Haulmont на позицию саппорт инженера поддерживать какую-то систему электронного документооборота. Стоит сказать, никакого профильного опыта у меня не было, да и теоретическая подготовка была не супер. Однако на удивление меня не выгнали с позором с собеседования, а даже позвали на второй этап. На втором этапе со мной общалась какая-то особо важная рекрутер (я до сих пор помню как ее зовут, это пригодилось, дальше расскажу как). Я понял, что она важная потому, как она уверенно себя вела и какие вопросы мне задавала. А вопросы ее были про то, как я вижу свое будущее - ведь на первом этапе собеседования, оказывается, я показал себя весьма средне. С ее слов, они могли бы меня взять "на вырост", а поэтому она хочет узнать мои мысли о будущем развитии. Тогда я мечтал когда-нибудь стать настоящим программистом, о чем и сообщил. Ее реакция меня сильно озадачила. Она в голос посмеялась, сидя в кресле передом мной. А потом серьезно посмотрела на меня и сказала, что шансов у меня нет. Мол, настоящие программисты с детства или подросткового возраста пишут код, участвуют в олимпиадах и вообще горят технологиями - а я уже не подросток, а даже программировать еще не умею. Не помню о чем мы говорили дальше, но в итоге я так и не стал там работать, вроде обещали перезвонить, а не перезвонили - в общем, не помню.
Однако история получила продолжение где-то через 5-7 лет.
Я уже давно забыл об этой истории, и работал себе разработчиком в другой компании (писал на Java). Т.к. Java и .Net имеют немало сходств, то по фану для себя изучал еще и .Net, писал на C#, даже с успехом сделал несколько тестовых заданий. В процессе поиска "новых путей развития", я пошел на собеседование в компаню Haulmont на позицию .Net разработчика. Дела давно минувших дней я не вспоминал, за это время и я стал другой, и компания. Собеседование прошло отлично, я уверенно чувствовал себя на теоретических вопросах, мы отлично пообщались с тимлидом. В общем, я получил оффер, но по совокупности факторов решил остаться в своей тогдашней компании. Через пару дней после отказа от оффера, я получил письмо от их другого рекрутера с предложением созвониться и обсудить варианты сотрудничества. И вы не поверите от кого было это письмо. Да, от того самого важного рекрутера, которая 5-7 лет назад смеялась мне в лицо и говорила, что я упустил время, чтобы стать программистом! Мы созвонились. Я не напоминал о прошлой истории, она предложила хороший для меня welcome бонус, если я соглашусь перейти к ним. Через пару часов письмо с условиями бонуса было у меня на почте, где я и сообщил ей о том, что отказываюсь от него.
Это не было моей вендеттой, я не разыграл эту карту полностью. Однако с тех пор эта история служит для меня живой иллюстрацией того, насколько недопустимо вести себя высокомерно с теми, кто ниже по квалификации или опыту. Уважение это базовый уровень отношения к человеку, даже если он еще зеленый новичок. Отношение к тем, кто в чем-то "ниже" - с тех пор для меня маркер культуры, который много говорит о человеке или команде.
Что-то получилось длинно и не совсем про неудачу. Остальные истории сделаю другим постом, там уже неудачи будут без триумфа.
Захотелось поделиться с вами парой историй своих карьерных неудач. Вдруг опыт их прохождения подбодрит кого-то.
"Как мне посмеялись в лицо о моей мечте стать программистом, а потом предлагали бонус за работу у них"
Первая история случилась в начале 2010-x годов. Я, будучи студентом первых курсов, собеседовался в компанию Haulmont на позицию саппорт инженера поддерживать какую-то систему электронного документооборота. Стоит сказать, никакого профильного опыта у меня не было, да и теоретическая подготовка была не супер. Однако на удивление меня не выгнали с позором с собеседования, а даже позвали на второй этап. На втором этапе со мной общалась какая-то особо важная рекрутер (я до сих пор помню как ее зовут, это пригодилось, дальше расскажу как). Я понял, что она важная потому, как она уверенно себя вела и какие вопросы мне задавала. А вопросы ее были про то, как я вижу свое будущее - ведь на первом этапе собеседования, оказывается, я показал себя весьма средне. С ее слов, они могли бы меня взять "на вырост", а поэтому она хочет узнать мои мысли о будущем развитии. Тогда я мечтал когда-нибудь стать настоящим программистом, о чем и сообщил. Ее реакция меня сильно озадачила. Она в голос посмеялась, сидя в кресле передом мной. А потом серьезно посмотрела на меня и сказала, что шансов у меня нет. Мол, настоящие программисты с детства или подросткового возраста пишут код, участвуют в олимпиадах и вообще горят технологиями - а я уже не подросток, а даже программировать еще не умею. Не помню о чем мы говорили дальше, но в итоге я так и не стал там работать, вроде обещали перезвонить, а не перезвонили - в общем, не помню.
Однако история получила продолжение где-то через 5-7 лет.
Я уже давно забыл об этой истории, и работал себе разработчиком в другой компании (писал на Java). Т.к. Java и .Net имеют немало сходств, то по фану для себя изучал еще и .Net, писал на C#, даже с успехом сделал несколько тестовых заданий. В процессе поиска "новых путей развития", я пошел на собеседование в компаню Haulmont на позицию .Net разработчика. Дела давно минувших дней я не вспоминал, за это время и я стал другой, и компания. Собеседование прошло отлично, я уверенно чувствовал себя на теоретических вопросах, мы отлично пообщались с тимлидом. В общем, я получил оффер, но по совокупности факторов решил остаться в своей тогдашней компании. Через пару дней после отказа от оффера, я получил письмо от их другого рекрутера с предложением созвониться и обсудить варианты сотрудничества. И вы не поверите от кого было это письмо. Да, от того самого важного рекрутера, которая 5-7 лет назад смеялась мне в лицо и говорила, что я упустил время, чтобы стать программистом! Мы созвонились. Я не напоминал о прошлой истории, она предложила хороший для меня welcome бонус, если я соглашусь перейти к ним. Через пару часов письмо с условиями бонуса было у меня на почте, где я и сообщил ей о том, что отказываюсь от него.
Это не было моей вендеттой, я не разыграл эту карту полностью. Однако с тех пор эта история служит для меня живой иллюстрацией того, насколько недопустимо вести себя высокомерно с теми, кто ниже по квалификации или опыту. Уважение это базовый уровень отношения к человеку, даже если он еще зеленый новичок. Отношение к тем, кто в чем-то "ниже" - с тех пор для меня маркер культуры, который много говорит о человеке или команде.
Что-то получилось длинно и не совсем про неудачу. Остальные истории сделаю другим постом, там уже неудачи будут без триумфа.
🔥14❤8💯6👍2
Заканчивая повествовательный перерыв от постов про технический и продуктовый менеджмент, расскажу еще 2 истории про карьерные неудачи. В предыдущей серии.
"Мы не можем тебя взять, в тебе недостаточно жесткости"
Это было в середине 2010-х годов, я работал старшим инженером в МегаФоне, отвечал за основную систему, в которой работают операторы всех контактных центров по России. В компании проходила очередная реструктуризация и в нашем направлении возник отдел т.н. "экспертов". Предполагалось, что по каждому техническому направлению будет "главный инженер", который будет лидить техническое развитие и принимать важные решения. На позиции этих экспертов был конкурс, в заявке помимо прочего должно быть видение развития направления, на которое ты подаешься. Я подал такую заявку и прошел на собеседование. Собеседование прошло отлично, я не завалил ни одного вопроса, да и в целом все было позитивно. Я был уверен в хорошем результате т.к. действительно был техническим экспертом в этом направлении.
Какого же было мое удивление и огорчение, когда я узнал, что меня НЕ берут на эту позицию. Вместо меня взяли коллегу из моей команды - к слову, он и правда был хорошим инженером. Следом за объявлением результатов, у меня была встреча с собеседующими, где они открыто дали обратную связь по моей заявке. Это был классический shit sandwich (кто понял, тот понял) - ключевой тезис был в том, что я слишком мягкий человек, у меня недостаточно жесткости, а поэтому я не смогу продавливать технические решения и подрядчиков. В работе этого эксперта действительно предполагалось много общения с подрядчиками, в которых действительно нужно было уметь выдерживать жесткую позицию. Прекинь, я проиграл.
Эта история подсветила для меня важную черту своего характера, на которую я не обращал внимания, но которая была заметна другим. С тех пор я помню об этой особенности своего поведения, замечаю его и корректирую, когда веду себя неадекватно ситуации. Кроме того это было для меня живым примером, как можно уступить в поле soft skills, и что наличие определенных софтов оказывается не данью культуре, а действительно рабочей необходимостью.
Одного лишь сильного желания недостаточно
Немногим позже этой истории я загорелся желанием стать системным/бизнес-аналитиком. Я видел в деле крутых ребят этой профессии, понимал их работу (на каком-то уровне). И мне было очень интересно.
В процессе поиска "новых путей развития", я подался на позицию системного аналитика (СА) в компанию Peter Service (ныне Nexign). Ранее какое-то время я работал плечом к плечу с СА + я уже имел какой-то опыт построения отказоустойчивых систем в МегаФоне + я программировал для себя на php и C#. Мне казалось, что это весомые аргументы в пользу моей компетентности.
Собеседование было в офисе компании и длилось чуть больше полутора часов. Для меня это было тяжеловато физически, но намного больше морально. Меня спрашивали про eTOM и TAM (это модели инфры и процессов телеком операторов), мне давали задачки по моделированию бизнес-процессов, мне давали задачки по системному дизайну - ничего из этого я не смог решить уверенно, плавал и отвечал с подсказками. На какие-то теоретические и практические вопросы я, конечно, ответил, и это внушило мне ложную надежду, что меня могут взять, а там я быстро все изучу.
Звонок рекрутера разрушил эту надежду - они ищут более сильного аналитика. Я помню как шел на обед по зимней улице и нес тяжелый ком в горле - мне так хотелось, а меня снова не взяли.
Эта история запечатлела в моей голове то, что одного лишь сильного желания чего-то получить недостаточно. Даже если есть аргументы в пользу желаемого - нужны действительно уверенные шаги в этом направлении. Возможно, именно этот урок придавал мне потом силы, что бы вечерами учиться программировать и глубже изучать "матчасть".
К слову, потом в этой компании я все таки поработал системным аналитиком, но это совсем другая история...
"Мы не можем тебя взять, в тебе недостаточно жесткости"
Это было в середине 2010-х годов, я работал старшим инженером в МегаФоне, отвечал за основную систему, в которой работают операторы всех контактных центров по России. В компании проходила очередная реструктуризация и в нашем направлении возник отдел т.н. "экспертов". Предполагалось, что по каждому техническому направлению будет "главный инженер", который будет лидить техническое развитие и принимать важные решения. На позиции этих экспертов был конкурс, в заявке помимо прочего должно быть видение развития направления, на которое ты подаешься. Я подал такую заявку и прошел на собеседование. Собеседование прошло отлично, я не завалил ни одного вопроса, да и в целом все было позитивно. Я был уверен в хорошем результате т.к. действительно был техническим экспертом в этом направлении.
Какого же было мое удивление и огорчение, когда я узнал, что меня НЕ берут на эту позицию. Вместо меня взяли коллегу из моей команды - к слову, он и правда был хорошим инженером. Следом за объявлением результатов, у меня была встреча с собеседующими, где они открыто дали обратную связь по моей заявке. Это был классический shit sandwich (кто понял, тот понял) - ключевой тезис был в том, что я слишком мягкий человек, у меня недостаточно жесткости, а поэтому я не смогу продавливать технические решения и подрядчиков. В работе этого эксперта действительно предполагалось много общения с подрядчиками, в которых действительно нужно было уметь выдерживать жесткую позицию. Прекинь, я проиграл.
Эта история подсветила для меня важную черту своего характера, на которую я не обращал внимания, но которая была заметна другим. С тех пор я помню об этой особенности своего поведения, замечаю его и корректирую, когда веду себя неадекватно ситуации. Кроме того это было для меня живым примером, как можно уступить в поле soft skills, и что наличие определенных софтов оказывается не данью культуре, а действительно рабочей необходимостью.
Одного лишь сильного желания недостаточно
Немногим позже этой истории я загорелся желанием стать системным/бизнес-аналитиком. Я видел в деле крутых ребят этой профессии, понимал их работу (на каком-то уровне). И мне было очень интересно.
В процессе поиска "новых путей развития", я подался на позицию системного аналитика (СА) в компанию Peter Service (ныне Nexign). Ранее какое-то время я работал плечом к плечу с СА + я уже имел какой-то опыт построения отказоустойчивых систем в МегаФоне + я программировал для себя на php и C#. Мне казалось, что это весомые аргументы в пользу моей компетентности.
Собеседование было в офисе компании и длилось чуть больше полутора часов. Для меня это было тяжеловато физически, но намного больше морально. Меня спрашивали про eTOM и TAM (это модели инфры и процессов телеком операторов), мне давали задачки по моделированию бизнес-процессов, мне давали задачки по системному дизайну - ничего из этого я не смог решить уверенно, плавал и отвечал с подсказками. На какие-то теоретические и практические вопросы я, конечно, ответил, и это внушило мне ложную надежду, что меня могут взять, а там я быстро все изучу.
Звонок рекрутера разрушил эту надежду - они ищут более сильного аналитика. Я помню как шел на обед по зимней улице и нес тяжелый ком в горле - мне так хотелось, а меня снова не взяли.
Эта история запечатлела в моей голове то, что одного лишь сильного желания чего-то получить недостаточно. Даже если есть аргументы в пользу желаемого - нужны действительно уверенные шаги в этом направлении. Возможно, именно этот урок придавал мне потом силы, что бы вечерами учиться программировать и глубже изучать "матчасть".
К слову, потом в этой компании я все таки поработал системным аналитиком, но это совсем другая история...
🔥7❤5👍4
Про пару паттернов рабочего использования AI
"Неопределенность" - частый спутник работы технического менеджера. Мы встречаемся с ней значительно чаще, чем хотелось бы:
- Решит ли новая фича пользовательскую задачу? А точно будет достаточный adoption или ею будут пользоваться полтора землекопа?
- Есть проблема X и она имеет несколько решений - какое подходит лучше с учетом нашей специфики? А может есть еще один более подходящий вариант?
- Возникла возможность Z. Стоит за нее схватиться и переделать планы или двигаться по намеченному ранее пути?
Прикол подобных вопросов в том, что в них может вообще не быть правильного ответа - никакого черного и белого, правильного или неправильного, только серый градиент. Для таких вопросов я приметил пару полезных паттернов использования LLM. Они помогают мне разогнать такие вопросы, ускорить собственный анализ и в итоге принять более взвешенное решение. Захотелось поделиться ими с вами.
1. Просить LLM задать мне важные вопросы по моему запросу ПЕРЕД ТЕМ как отвечать по делу
У такого подхода есть одновременно две пользы. Во-первых, вопросы от LLM частенько помогают задуматься о том, чего не было изначально "на столе". Т.е. я и не думал о том, что такие вопросы могут возникнуть при размышлении над своим делом. Такие вопросы заставляют задуматься и посмотреть на дело немного под другим углом. А если они совпадают с тем, о чем я и так думал, то немного укрепиться, что вопросы действительно make sense. Кроме того, я могу углубляться в какие-то вопросы от LLM, которые показались мне важными или непонятными ("Не знаю, что ответить на этот вопрос. Давай порассуждаем вместе над вариантами"). Это приводит к тому, что мы работаем уже не в формате запрос-решение, а скорее в коллаборации или диалоге - модель обучает меня в том, что я не понимаю, а я обогащаю ее специфичным контекстом. И мы вместе нацелены на выбор лучшего решения моей задачи.
Во-вторых, ответы на такие вопросы обогащают диалог контекстом, который специфичен именно для моей ситуации. Это помогает модели сделать предложение, которое лучше всего подходит именно в моей истории.
Ну и, конечно, для таких случаев лучше использовать мощные размышляющие модели типа Gemini 3 Pro или Opus 4.5. С слабыми моделями такой подход не так эффективен.
2. Использовать голос в качестве способа ввода
Сначала я противился голосовому вводу - мне казалось, что печатание текста выпрямляет мысль и даже само формулирование вопросов уже приближает к решению (и так реально бывало!). Однако когда я наслушался более опытных в AI-деле ребят и попробовал голосовой ввод, то очень удивился тому, насколько это ускоряет взаимодействие и привносит в диалог детали, которые я бы не приметил в письме. Поэтому частенько я теперь включаю голосовой ввод на ноуте и спрашиваю модель голосом, также наговариваю и ответы на вопросы.
3. Использовать Cursor не только для кода
В Cursor очень удобно писать и отлаживать код, но оказалось, что удобно и обсуждать продуктовые вопросики. Используя паттерны выше накидываю в Cursor свою задачу, отвечаю на вопросы, задаю новые, углубляюсь в непонятные. На выходе прошу написать md-документ по моей задаче, в диалоге довожу его до нужного мне состояния. Но ценность, конечно, не в документе, а в том знании по своему вопросу, которое я приобретаю в процессе.
В такой коллабе недавно создал сложный excel-документ - сначала мы обсудили в Cursor задачу, потом он ушел с помощью каких-то либ в Python делать сам Excel-файл. Потом мы прошли N итераций ревью - я давал замечания, он делал правки, я открывал Excel и проверял. В результате получился очень неплохой и непростой Excel, это реально сэкономило мне часы работы.
"Неопределенность" - частый спутник работы технического менеджера. Мы встречаемся с ней значительно чаще, чем хотелось бы:
- Решит ли новая фича пользовательскую задачу? А точно будет достаточный adoption или ею будут пользоваться полтора землекопа?
- Есть проблема X и она имеет несколько решений - какое подходит лучше с учетом нашей специфики? А может есть еще один более подходящий вариант?
- Возникла возможность Z. Стоит за нее схватиться и переделать планы или двигаться по намеченному ранее пути?
Прикол подобных вопросов в том, что в них может вообще не быть правильного ответа - никакого черного и белого, правильного или неправильного, только серый градиент. Для таких вопросов я приметил пару полезных паттернов использования LLM. Они помогают мне разогнать такие вопросы, ускорить собственный анализ и в итоге принять более взвешенное решение. Захотелось поделиться ими с вами.
1. Просить LLM задать мне важные вопросы по моему запросу ПЕРЕД ТЕМ как отвечать по делу
Хочу решить задачу X. Контекст вопроса Y. Задай мне 5-7 наиболее важных вопросов, которые помогут тебе лучше понять мою ситуацию и дать лучший ответ. Не отвечай по существу вопроса пока я не попрошу явно.
У такого подхода есть одновременно две пользы. Во-первых, вопросы от LLM частенько помогают задуматься о том, чего не было изначально "на столе". Т.е. я и не думал о том, что такие вопросы могут возникнуть при размышлении над своим делом. Такие вопросы заставляют задуматься и посмотреть на дело немного под другим углом. А если они совпадают с тем, о чем я и так думал, то немного укрепиться, что вопросы действительно make sense. Кроме того, я могу углубляться в какие-то вопросы от LLM, которые показались мне важными или непонятными ("Не знаю, что ответить на этот вопрос. Давай порассуждаем вместе над вариантами"). Это приводит к тому, что мы работаем уже не в формате запрос-решение, а скорее в коллаборации или диалоге - модель обучает меня в том, что я не понимаю, а я обогащаю ее специфичным контекстом. И мы вместе нацелены на выбор лучшего решения моей задачи.
Во-вторых, ответы на такие вопросы обогащают диалог контекстом, который специфичен именно для моей ситуации. Это помогает модели сделать предложение, которое лучше всего подходит именно в моей истории.
Ну и, конечно, для таких случаев лучше использовать мощные размышляющие модели типа Gemini 3 Pro или Opus 4.5. С слабыми моделями такой подход не так эффективен.
2. Использовать голос в качестве способа ввода
Сначала я противился голосовому вводу - мне казалось, что печатание текста выпрямляет мысль и даже само формулирование вопросов уже приближает к решению (и так реально бывало!). Однако когда я наслушался более опытных в AI-деле ребят и попробовал голосовой ввод, то очень удивился тому, насколько это ускоряет взаимодействие и привносит в диалог детали, которые я бы не приметил в письме. Поэтому частенько я теперь включаю голосовой ввод на ноуте и спрашиваю модель голосом, также наговариваю и ответы на вопросы.
3. Использовать Cursor не только для кода
В Cursor очень удобно писать и отлаживать код, но оказалось, что удобно и обсуждать продуктовые вопросики. Используя паттерны выше накидываю в Cursor свою задачу, отвечаю на вопросы, задаю новые, углубляюсь в непонятные. На выходе прошу написать md-документ по моей задаче, в диалоге довожу его до нужного мне состояния. Но ценность, конечно, не в документе, а в том знании по своему вопросу, которое я приобретаю в процессе.
В такой коллабе недавно создал сложный excel-документ - сначала мы обсудили в Cursor задачу, потом он ушел с помощью каких-то либ в Python делать сам Excel-файл. Потом мы прошли N итераций ревью - я давал замечания, он делал правки, я открывал Excel и проверял. В результате получился очень неплохой и непростой Excel, это реально сэкономило мне часы работы.
🔥11👍5❤1
WHERE 1=1
А вы знаете, зачем люди вставляют в SQL запросы условие "1=1"? "Это же бессмысленное условие!?" - так думал я, пока когда-то не пришлось всерьез и надолго поработать с SQL. Оказалось, это очень удобно.
1. Упрощение кодовой генерации запросов
Когда ты делаешь SQL-запросы из кода, то дефолтная вставка "WHERE 1=1" позволяет все дополнительные условия выборки вставлять через AND. Ты просто добавляешь "AND segment = "Enterprise" и не паришься, есть ли там хотя бы одно условие. Так проще и меньше возможности набаговать.
2. Удобство изменения запроса
Когда я анализирую какие-то данные в БД (а мне это частенько приходится делать для разных продуктовых задач), то за счет "WHERE 1=1" я могу очень быстро включать/выключать какие-то условия выборки без изменения структуры запроса. Захотел убрать условие с полем - просто закомментировал всю строчку и все. Это очень ускоряет, когда ты только подбираешь подходящий запрос.
А вы знали про эту штуку?
SELECT customer_id, segment
FROM customers
WHERE 1=1
AND segment = "Enterprise"
А вы знаете, зачем люди вставляют в SQL запросы условие "1=1"? "Это же бессмысленное условие!?" - так думал я, пока когда-то не пришлось всерьез и надолго поработать с SQL. Оказалось, это очень удобно.
1. Упрощение кодовой генерации запросов
Когда ты делаешь SQL-запросы из кода, то дефолтная вставка "WHERE 1=1" позволяет все дополнительные условия выборки вставлять через AND. Ты просто добавляешь "AND segment = "Enterprise" и не паришься, есть ли там хотя бы одно условие. Так проще и меньше возможности набаговать.
2. Удобство изменения запроса
Когда я анализирую какие-то данные в БД (а мне это частенько приходится делать для разных продуктовых задач), то за счет "WHERE 1=1" я могу очень быстро включать/выключать какие-то условия выборки без изменения структуры запроса. Захотел убрать условие с полем - просто закомментировал всю строчку и все. Это очень ускоряет, когда ты только подбираешь подходящий запрос.
SELECT * FROM customers
WHERE 1=1
-- AND status = "active"
AND country = "RU";
А вы знали про эту штуку?
💯8👍6🔥4