Спасибо за оценку исследования, мы старались:) Момент про софт-скиллы мы тоже отметили — действительно интересно, почему их мало развивают с помощью дополнительных инструментов (курсов, терапии и т.п.). Что касается терапии, то как раз сегодня вышел эпизод нашего подкаста make sense, где мы обсуждали софт-скиллы: что к ним относится, как их развивать, почему важна терапия. Можно послушать вот тут: https://t.me/mspodcast/394
Можете применить инновацию — вытатуировать свой бренд у себя на лбу
Есть люди готовые и на такие радикальные вещи, но мы ведь о правильно соотношении затраченных усилий и результата говорим, правда? :)
И, да, большое спасибо за совет применения Agile к семейной жизни
Agile немного не о том, и статья немного не про него.
Формулируя идею статьи кратко: Можно думать о привычных нам вещах, как продуктах. Это позволяет нам применять к ним практики продуктового мышления. Задавать вопросы — почему именно так? Какую проблему это решает? Как можно сделать лучше? Конструктивно выстраивая причинно-следственные связи мы сможем встать на путь развития и совершенствования продукта.
Вопрос про отношения. Это всегда про две стороны. И нет одного ответственного за них. Но можно примерить на себя роль менеджера продукта, рассматривая свой вклад в отношения:
Например я разозлился, когда моя вторая половинка оказалась занята вечером, и мы не смогли встретиться.
Почему я веду себя именно так? Меня лишили приятного время провождения.
А раньше ты злился? Нет
Почему? Мы виделись чаще, 2 раза в неделю
А сейчас? Реже, 1 раз
Почему? Заняты
Что можно сделать? Видеться чаще
Как? Ну, наверное мы можем обедать вместе
Очень просто пример из головы, и его можно усложнять, но идея примерно такая. Продуктовое мышление про конструктив и осознанность.
вот это вот все «не видно надписи/узнают футболку/распространяют что-то там»
В мире спорта и других публичный событий это очень важные задачи, т.к. люди инвестируют деньги в охват аудитории. Считает например что и как долго появлялось в кадре, под каким углом. Это очень сложные системы (в интернете пишут, что скорость Криштиану Роналду достигает 38,6 км/ч) распознавания образов. Когда речь идет о большом количестве денег — миллионах долларов — многое становится важным.
Если человек занимаете только теми задачами, которые он легко решает значит, что он не развивается, а только затачивает навыки. Чтобы был рост необходимы задачи, которые будут либо очень сложными, либо не выполнимыми. Это дает толчек к развитию.
>Стоящий технический опыт — стоит денег, серьезных денег, не 20-100 баксов за вход на конференцию. Это будут тысячи и закрытые мастерклассы, скорее всего.
Абсолютно верно. Для тех кто стесняется задавать вопросы и боится подходить к людям.
На конференции легко поймать за рукав эксперта, поделиться с ним проблемой и он будет готов помочь — потому что он вырван из ежедневных дел, его сюда привезли (и возможно даже заплатили за это).
В общем, хорошего менеджера, умеющего работать не только с заказчиком, но и с исполнителями, также трудно найти как и хорошего разработчика.
И это абсолютная истина.
В тексте как раз речь о том, что и за менеджерами бывают такие грехи. Стыдиться этого или нет — это выбор личный. На мой взгляд открыто говорить о проблеме — это один из шагов на пути к её решению.
Вы верно замечаете, что момент когда начинается разработка MVP может стать моментом, в который начинает накапливаться технический долг.
Перед публикацией, я скидывал статью одному из наших ведущих разработчиков и он тоже указал на этот момент:
А что если после очередного mvp, у тебя не будет времени на осмысление написанного тобою за этот период кода? и дальше тебя ждет очередное mvp? что станет с этим кодом?
И все же.
Фраза «пользователям не нужна идеальная архитектура, потому что они никогда ее не увидят» похожа на «гражданам нашей страны не нужен уголь, потому что напрямую они его не потребляют»
Я склоняюсь к тому, что до тех пор, пока архитектура не мешает причинению пользы клиентам и развитию бизнеса, её можно приносить в жертву (это trade-off — компромисс). В тот момент, когда это начинает мешать развитию — этим стоит серьезно заняться.
И классно, когда разработчик понимает (будучи погруженным в контекст), что здесь и здесь в перспективе может быть развитие архитектуры в такие то модули, а здесь может быть вот так. И закладывает это в фундамент, тратя на это минимум времени.
Речь не совсем про гибкие подходы, а скорее про отношение к тому, что и как делается.
Можно быть сколько угодно гибкими и не делать то, что действительно нужно. И можно использовать waterfall, и при этом решать задачи/проблемы клиентов и все будут довольно. Это всего лишь инструменты.
.
Спасибо за оценку исследования, мы старались:) Момент про софт-скиллы мы тоже отметили — действительно интересно, почему их мало развивают с помощью дополнительных инструментов (курсов, терапии и т.п.). Что касается терапии, то как раз сегодня вышел эпизод нашего подкаста make sense, где мы обсуждали софт-скиллы: что к ним относится, как их развивать, почему важна терапия. Можно послушать вот тут: https://t.me/mspodcast/394
Есть люди готовые и на такие радикальные вещи, но мы ведь о правильно соотношении затраченных усилий и результата говорим, правда? :)
Agile немного не о том, и статья немного не про него.
Формулируя идею статьи кратко: Можно думать о привычных нам вещах, как продуктах. Это позволяет нам применять к ним практики продуктового мышления. Задавать вопросы — почему именно так? Какую проблему это решает? Как можно сделать лучше? Конструктивно выстраивая причинно-следственные связи мы сможем встать на путь развития и совершенствования продукта.
Вопрос про отношения. Это всегда про две стороны. И нет одного ответственного за них. Но можно примерить на себя роль менеджера продукта, рассматривая свой вклад в отношения:
Например я разозлился, когда моя вторая половинка оказалась занята вечером, и мы не смогли встретиться.
Почему я веду себя именно так? Меня лишили приятного время провождения.
А раньше ты злился? Нет
Почему? Мы виделись чаще, 2 раза в неделю
А сейчас? Реже, 1 раз
Почему? Заняты
Что можно сделать? Видеться чаще
Как? Ну, наверное мы можем обедать вместе
Очень просто пример из головы, и его можно усложнять, но идея примерно такая. Продуктовое мышление про конструктив и осознанность.
В мире спорта и других публичный событий это очень важные задачи, т.к. люди инвестируют деньги в охват аудитории. Считает например что и как долго появлялось в кадре, под каким углом. Это очень сложные системы (в интернете пишут, что скорость Криштиану Роналду достигает 38,6 км/ч) распознавания образов. Когда речь идет о большом количестве денег — миллионах долларов — многое становится важным.
У штанов похожа проблема — культурно не принято смотреть на штаны, хотя пилотов формулы один это не останавливает.
>Стоящий технический опыт — стоит денег, серьезных денег, не 20-100 баксов за вход на конференцию. Это будут тысячи и закрытые мастерклассы, скорее всего.
Абсолютно верно. Для тех кто стесняется задавать вопросы и боится подходить к людям.
На конференции легко поймать за рукав эксперта, поделиться с ним проблемой и он будет готов помочь — потому что он вырван из ежедневных дел, его сюда привезли (и возможно даже заплатили за это).
И это абсолютная истина.
В тексте как раз речь о том, что и за менеджерами бывают такие грехи. Стыдиться этого или нет — это выбор личный. На мой взгляд открыто говорить о проблеме — это один из шагов на пути к её решению.
Вы верно замечаете, что момент когда начинается разработка MVP может стать моментом, в который начинает накапливаться технический долг.
Перед публикацией, я скидывал статью одному из наших ведущих разработчиков и он тоже указал на этот момент:
И все же.
Я склоняюсь к тому, что до тех пор, пока архитектура не мешает причинению пользы клиентам и развитию бизнеса, её можно приносить в жертву (это trade-off — компромисс). В тот момент, когда это начинает мешать развитию — этим стоит серьезно заняться.
И классно, когда разработчик понимает (будучи погруженным в контекст), что здесь и здесь в перспективе может быть развитие архитектуры в такие то модули, а здесь может быть вот так. И закладывает это в фундамент, тратя на это минимум времени.
Можно быть сколько угодно гибкими и не делать то, что действительно нужно. И можно использовать waterfall, и при этом решать задачи/проблемы клиентов и все будут довольно. Это всего лишь инструменты.
Важен результат.