В ML все работает иначе. Команда включается уже на этапе исследования, погружается в бизнес-цели и техническую постановку задачи.
Подумалось, что дело не столько в ML, сколько в уровне неопределённости. Раньше вотерфол работал, потому что задачи были +/- понятные, с низкой неопределённостью.
Сейчас в ML уровень неопределённости высок по умолчанию, поэтому и вылезли гибкие методологии. Но это не значит, что через пару лет в ML нельзя будет вотерфолить — как только уровень неопределённости снизится, предсказуемый результат станет важнее гибкости.
...как ML-метрики будут связаны с продуктовыми и бизнес-метриками
А можете подробнее рассказать? Можно даже очередную статью на эту тему, настолько интересно.
Простор для геймификации: новым авторам придётся прорываться через блэклист, побеждая одного гонщика юзера за другим и повышая уровень внимания полиции модерации...
Для меня проблема далеко идущего личного планирования как раз в том, что на длительном промежутке сложно себя контролировать. Проще договориться с собой на четыре тяжёлых силовых тренировки в неделю, чем сразу заложиться на Мистера Олимпию через десять лет. Хотя при определённом усердии и регулярных инъекциях тренболона результат будет +/- один.
Коротко подход можно описать так: проводится стратегическая сессия в одно лицо. При этом не так уж важно, какие именно методики используются.
Но описанная методика норм, есть даже типичный для стратегических коучей wow-момент: выкидываем желания, чтобы определить приоритеты от противного.
Слышал, что одарённые люди проводят такие сессии на пару с жёнами/мужьями, чтобы определить цели пары на год. Как по мне, это верный способ убить в себе остатки сексуальности и перестать нравиться жене. Но наедине с собой почему бы и нет)
Пачка вопросов:
Контролируете ли прогресс? Если да, то как регулярно?
Как часто пересматриваете стратегию?
Что делаете, если стратегия составлена, но ленивый исполнитель продуманный стратег её саботирует?
Мысль понятна, лонгриды действительно замечательные. Единственный момент: устать можно от любой темы. Как по мне, пусть будет больше статей, хороших и разных.
Лишь бы категоризировалось всё правильно, с чем у всех упомянутых проблем нет)
И показалось, что пример факап-ревью выбран безопасный. Вы столкнулись с проблемами из-за ошибки, но выкатили решение — и рассказали об этом только потом. А если взять более негативный сценарий?
Допустим, проект был переведён на технологию, которая не оправдала ожиданий — и теперь нужно выбить у бизнеса время на ещё один переезд. В этом случае будете проводить факап-ревью или другими инструментами воспользуетесь?
Спасибо за статьи, обе прочёл с удовольствием! Есть вопрос про обсуждение проблем: достаточно ли факап-ревью, чтобы в команде сохранялось спокойное отношение к ошибкам? Или как-то ещё поддерживаете нужную атмосферу?
Спрашиваю, потому что признавать ошибки трудно. Если менеджмент собственным примером не показывает, что ошибки — это нормально, со временем команда может вернуться в естественное состояние с «отрицательным ростом»)
Я не включал телевизор, пока младшая дочка не почитает. Старшая находила свои аргументы и даже сама с ней читала, пока я был занят. Когда от тебя зависят другие, ты более мотивирован.
Кажется, что более мотивированной здесь была не младшая, а старшая) И на корпоративные будни перекладывается странно: навязываешь джуна опытному сотруднику, при этом вместо профита — угроза отнять («не выплачу обычную премию, пока джун не X»).
интервью с пользователями недостаточно – их должны дополнять метрики
Это очень важная мысль. Ни NPS, ни кастдев-интервью, ни модная (и довольно крутая) модель Кано — это не замена живым поведенческим метрикам. Люди могут говорить одно, а делать другое. Важность эмоций и обратной связи это не умаляет, но помнить полезно.
Есть вопрос: получалось ли у вас одновременно растить и объективные метрики продукта, и условное счастье пользователей? Спрашиваю, потому что сам часто наблюдаю развитие продукта циклами: вот тут мы работаем на NPS, а здесь проталкиваем пользователей по воронкам и занимаемся монетизацией/удержанием. Иногда это делается одновременно, но силами разных команд.
В оригинале книга называется Software Development Pearls, что как бы намекает на Programming Pearls Джона Бентли. Бентли давно на слуху, так что название может создавать ложные ассоциации. Programming Pearls однозначно для разработчиков, а эта книга больше для манагеров, хотя и разрабам может быть интересна.
Не ждите в Software Development Pearls откровений о программировании, она про процессы. Впрочем, по отрывку в статье можно догадаться)
Спасибо, за издание на русском! Перечитаю с удовольствием.
По состоянию на 10:00 по мск два самых рейтинговых совета написали @Vsevo10d и @Sergiv — мои поздравления, наборы мерча достаются вам! Подробности напишу в личку.
Вы рассуждаете так, как будто каждый автор-одиночка физически не способен к общению с коллегами. Но это не так: будучи самостоятельным автором, вы можете консультироваться со знакомыми специалистами — и улучшать статьи за счёт информации из областей, в которых сами недостаточно разбираетесь. Да и с незнакомыми людьми тоже можно консультироваться: профессионалы охотно помогают, когда тема статьи им интересна.
Насколько бы хорошие редакционные процессы не выстроила компания — она не может запатентовать IT-журналистику. Вы можете пользоваться любыми журналистскими приёмами в домашних условиях, без риска для здоровья и с минимальными усилиями — нужно всего лишь обратиться к другим людям, когда чувствуете, что сами не вывозите. Многие независимые авторы так уже делают.
При всём вышесказанном: написание статей устроено сложнее, чем драка. Нельзя недооценивать творческий фактор — порой наличие соавторов только мешает. Ох, сколько же таких статей-франкенштейнов я успел перечитать.
В этом году 14 авторов-одиночек победило в Технотексте. Без дополнительных условий: просто их статьи судьи сочли лучшими. Вы же предлагаете сгонять одиночек в отдельную ветку, чтобы там они соревновались друг с другом. При этом по вашей логике получается, что ветка одиночек — это лягушатник. Мол, настоящие зарубы будут проходить в корпоративном сегменте, где у каждого личный редактор и есть доступ к магии общения с коллегами.
Извините, но я с этим не согласен. Любой автор-одиночка переиграет большую корпорацию, если у него есть экспертиза, способность внятно излагать мысли и то, что называется журналистской чуйкой. На Хабре полно таких независимых авторов. Им не нужны поблажки и особые условия оценки. Осмелюсь предположить, что кто-то бы даже счёл это оскорбительным.
Здесь стоит уточнить, что правила для компаний такие же, как для авторов-одиночек. А именно: один автор — одна статья. И каждый автор от компании оценивается сам по себе, общекомандного зачёта у нас нет.
Попадание одного из авторов компании в шорт-лист не гарантирует, что остальные окажутся там же. Корпоративные авторы проходят в финал на общих основаниях. Шансы автора-одиночки это уменьшает в той же степени, что и увеличение количества хороших статей в номинации.
Вечеринку откладываем до лучших времён, сейчас она бы выглядела не очень уместно. Да и собрать победителей/номинантов сложно, многие не в России.
В статье уже писал, но продублирую, чтобы в комментариях тоже было:
Если вы внимательно читали лендинг конкурса, то помните, что мы обещали вечеринку. Думаю, многие согласятся, что устраивать масштабный праздник прямо сейчас было бы неуместно. Поэтому пока мы ограничимся конкурсом в комментариях, а идею собрать топовых авторов Хабра в оффлайне прибережём на потом. Лично я с нетерпением жду такой возможности.
Выкладываю подробности о конкурсе) Начинающие авторы спрашивают:
Как написать статью, чтобы она понравилась читателям Хабра?
Попробуйте ответить на этот вопрос, а потом пройдитесь по другим комментариям и плюсаните те, с которыми согласны. Авторы двух самых рейтинговых советов получат набор мерча: свитшот и шоппер. Ваши комментарии могут стать частью обучающих материалов для новичков на Хабре.
Небольшая просьба: не оставляйте конкурсные ответы в чужих ветках. Итоги подведём утром в понедельник, 17 апреля.
Подумалось, что дело не столько в ML, сколько в уровне неопределённости. Раньше вотерфол работал, потому что задачи были +/- понятные, с низкой неопределённостью.
Сейчас в ML уровень неопределённости высок по умолчанию, поэтому и вылезли гибкие методологии. Но это не значит, что через пару лет в ML нельзя будет вотерфолить — как только уровень неопределённости снизится, предсказуемый результат станет важнее гибкости.
А можете подробнее рассказать? Можно даже очередную статью на эту тему, настолько интересно.
Простор для геймификации: новым авторам придётся прорываться через блэклист, побеждая одного
гонщикаюзера за другим и повышая уровень вниманияполициимодерации...Простите, олдскулы свело
Спасибо за ответы и статью, было интересно!
Для меня проблема далеко идущего личного планирования как раз в том, что на длительном промежутке сложно себя контролировать. Проще договориться с собой на четыре тяжёлых силовых тренировки в неделю, чем сразу заложиться на Мистера Олимпию через десять лет. Хотя при определённом усердии
и регулярных инъекциях тренболонарезультат будет +/- один.Коротко подход можно описать так: проводится стратегическая сессия в одно лицо. При этом не так уж важно, какие именно методики используются.
Но описанная методика норм, есть даже типичный для стратегических коучей wow-момент: выкидываем желания, чтобы определить приоритеты от противного.
Слышал, что одарённые люди проводят такие сессии на пару с жёнами/мужьями, чтобы определить цели пары на год. Как по мне, это верный способ убить в себе остатки сексуальности и перестать нравиться жене. Но наедине с собой почему бы и нет)
Пачка вопросов:
Контролируете ли прогресс? Если да, то как регулярно?
Как часто пересматриваете стратегию?
Что делаете, если стратегия составлена, но
ленивый исполнительпродуманный стратег её саботирует?Слава, спасибо за хорошие истории! И отдельно за постанализ: выводы показались мне справедливыми, буду с нетерпением ждать новых публикаций.
Мысль понятна, лонгриды действительно замечательные. Единственный момент: устать можно от любой темы. Как по мне, пусть будет больше статей, хороших и разных.
Лишь бы категоризировалось всё правильно, с чем у всех упомянутых проблем нет)
И показалось, что пример факап-ревью выбран безопасный. Вы столкнулись с проблемами из-за ошибки, но выкатили решение — и рассказали об этом только потом. А если взять более негативный сценарий?
Допустим, проект был переведён на технологию, которая не оправдала ожиданий — и теперь нужно выбить у бизнеса время на ещё один переезд. В этом случае будете проводить факап-ревью или другими инструментами воспользуетесь?
Спасибо за статьи, обе прочёл с удовольствием! Есть вопрос про обсуждение проблем: достаточно ли факап-ревью, чтобы в команде сохранялось спокойное отношение к ошибкам? Или как-то ещё поддерживаете нужную атмосферу?
Спрашиваю, потому что признавать ошибки трудно. Если менеджмент собственным примером не показывает, что ошибки — это нормально, со временем команда может вернуться в естественное состояние с «отрицательным ростом»)
Да я больше о том, что до появления «джуна» премия была безусловной. Вот если бы за чтение давали мороженое, которого раньше не было...)
Так в статье написано, что он бэкендер)
Шутка про ленивых разрабов, которая всего лишь шутка
Кажется, что более мотивированной здесь была не младшая, а старшая) И на корпоративные будни перекладывается странно: навязываешь джуна опытному сотруднику, при этом вместо профита — угроза отнять («не выплачу обычную премию, пока джун не X»).
Это очень важная мысль. Ни NPS, ни кастдев-интервью, ни модная (и довольно крутая) модель Кано — это не замена живым поведенческим метрикам. Люди могут говорить одно, а делать другое. Важность эмоций и обратной связи это не умаляет, но помнить полезно.
Есть вопрос: получалось ли у вас одновременно растить и объективные метрики продукта, и условное счастье пользователей? Спрашиваю, потому что сам часто наблюдаю развитие продукта циклами: вот тут мы работаем на NPS, а здесь проталкиваем пользователей по воронкам и занимаемся монетизацией/удержанием. Иногда это делается одновременно, но силами разных команд.
В оригинале книга называется Software Development Pearls, что как бы намекает на Programming Pearls Джона Бентли. Бентли давно на слуху, так что название может создавать ложные ассоциации. Programming Pearls однозначно для разработчиков, а эта книга больше для манагеров, хотя и разрабам может быть интересна.
Не ждите в Software Development Pearls откровений о программировании, она про процессы. Впрочем, по отрывку в статье можно догадаться)
Спасибо, за издание на русском! Перечитаю с удовольствием.
По состоянию на 10:00 по мск два самых рейтинговых совета написали @Vsevo10d и @Sergiv — мои поздравления, наборы мерча достаются вам! Подробности напишу в личку.
Вы рассуждаете так, как будто каждый автор-одиночка физически не способен к общению с коллегами. Но это не так: будучи самостоятельным автором, вы можете консультироваться со знакомыми специалистами — и улучшать статьи за счёт информации из областей, в которых сами недостаточно разбираетесь. Да и с незнакомыми людьми тоже можно консультироваться: профессионалы охотно помогают, когда тема статьи им интересна.
Насколько бы хорошие редакционные процессы не выстроила компания — она не может запатентовать IT-журналистику. Вы можете пользоваться любыми журналистскими приёмами в домашних условиях, без риска для здоровья и с минимальными усилиями — нужно всего лишь обратиться к другим людям, когда чувствуете, что сами не вывозите. Многие независимые авторы так уже делают.
При всём вышесказанном: написание статей устроено сложнее, чем драка. Нельзя недооценивать творческий фактор — порой наличие соавторов только мешает. Ох, сколько же таких статей-франкенштейнов я успел перечитать.
В этом году 14 авторов-одиночек победило в Технотексте. Без дополнительных условий: просто их статьи судьи сочли лучшими. Вы же предлагаете сгонять одиночек в отдельную ветку, чтобы там они соревновались друг с другом. При этом по вашей логике получается, что ветка одиночек — это лягушатник. Мол, настоящие зарубы будут проходить в корпоративном сегменте, где у каждого личный редактор и есть доступ к магии общения с коллегами.
Извините, но я с этим не согласен. Любой автор-одиночка переиграет большую корпорацию, если у него есть экспертиза, способность внятно излагать мысли и то, что называется журналистской чуйкой. На Хабре полно таких независимых авторов. Им не нужны поблажки и особые условия оценки. Осмелюсь предположить, что кто-то бы даже счёл это оскорбительным.
Здесь стоит уточнить, что правила для компаний такие же, как для авторов-одиночек. А именно: один автор — одна статья. И каждый автор от компании оценивается сам по себе, общекомандного зачёта у нас нет.
Попадание одного из авторов компании в шорт-лист не гарантирует, что остальные окажутся там же. Корпоративные авторы проходят в финал на общих основаниях. Шансы автора-одиночки это уменьшает в той же степени, что и увеличение количества хороших статей в номинации.
Эх, за второе место пока ничего не даём. Но статья у вас отличная!
Мем в тему
Вечеринку откладываем до лучших времён, сейчас она бы выглядела не очень уместно. Да и собрать победителей/номинантов сложно, многие не в России.
В статье уже писал, но продублирую, чтобы в комментариях тоже было:
Выкладываю подробности о конкурсе) Начинающие авторы спрашивают:
Попробуйте ответить на этот вопрос, а потом пройдитесь по другим комментариям и плюсаните те, с которыми согласны. Авторы двух самых рейтинговых советов получат набор мерча: свитшот и шоппер. Ваши комментарии могут стать частью обучающих материалов для новичков на Хабре.
Небольшая просьба: не оставляйте конкурсные ответы в чужих ветках. Итоги подведём утром в понедельник, 17 апреля.