что я щас прочитал вообще: задачи накидали в итерацию по приницпу "и так сойдет", не было грумминга, предварительной оценки и планирования (где на каждого сначала смотрится наличие свободного времени, а потом планируется не под шапочку, а с небольшим запасом), и потом не было ежедневных стендапов, где каждый если что говорит, если перевел задачу в ожидание, и что от кого ждет.
Чтобы избавиться от всех вышеописанных проблем в зародыше, требуется всего лишь планировать людей на итерацию и ежедневно с утра командой синкаться. И тогда все эти фильтры не нужны, ведь они вынесены на стадии на доске, и по ним ответственный сотрудник должен будет рассказать.
как бывший игрок в покер очень многое переосмыслил в работе, как раз начав применять "дистанция все вернет" (не вернет) и "результат - лишь следствие правильно принятых решений". Вероятностный подход прекрасен, но не стоит забывать и о дисперсии, особенно в высокорисковых решениях - та самая дистанция может не успеть вернуть, и всегда важно оглядываться и иногда принимать неоптимальные, но более стабильные решения ради будущих возможностей. Вода водой, конечно, но когда ты начинаешь думать не решением, а спектром решений, по сути переходишь от уровня принятия решения к уровню принятия стратегии, сразу меняется взгляд на бизнес и карьеру
Добро пожаловать в бизнес-анализ. Системная аналитика как обычно ни при чем)
Работой системного аналитика было бы писать в отдельную таблицу акционные убытки, чтобы потом бизнес-аналитику можно было простым селектом сделать выборку из этой таблицы без заморочек со сложносочиненным sql) Хотя навык безусловно не лишний. В своей практике так же при разборе проблем с БД использую ИИ для помощи в написании sql, но мы оптимизировали с рарзработкой сбор данных в бд так, чтобы с ним можно было поэтапно отработать и возрадоваться наиболее быстрым способом
нет, я закидываю документ, формат ожидаемого ответа, и получаю что-то. У системы просто не хватает пласта данных, как и у меня на старте, так что путь тут просто закрыт. Легаси, плохая документированность и прочие радости, все как руками, нет тут вины ИИ, есть проблема, что этот класс задач не решаем на текущем уровне, но даже так ИИ предусматривает больше, чем миддл-аналитик и тестер уже сейчас, это подкупает
я не каждый день играю в системного архитектора. Проекты не длятся 2-4 дня, это месяцы разработки, поэтому ежедневно нет смысла. Речь про реальный сектор, производственные и торговые блоки на предприятиях с оборотом как ВВП моей области, если не целой страны. Поэтому да, проще загнать условия и получить черновик схемы раз, а потом уже команда и арх.комитет уточняет
тут дело в том, что ИИшница встроена в ТОЛК. Ваще ниче не надо, кроме причесать. Но отдать непричесанный вариант тоже можно без флоу и попросить саммари по саммари (надо увидеть раз Толковые расшифровки, чтобы понять, о чем я, там просто блоки почти дублируются местами, и их приходится разделять). Но делать еще и флоу не хочется, попробую загонять результат ИИ в еще один ИИ, быстрее будет)
А поделитесь своими кейсами использования ИИ в проектном менеджменте? Практическими, что и как хочется получать, что делаете, какими ИИ пользуетесь. Я начну)
2 месяца назад пошел в Дипсик. Использую для:
а) написании сложных для меня sql-ек
б) разборе логов по предусловиям (условия и логику обозначаю - получаю возможные проблемы или точки отказа)
в) подготовке проектной документации и особенно тестирования на основе функ.требований/постановки. Главное, не скупиться на буквы и с параметрами и четкими обозначениями определять в промте таблицы БД, сервисы, сервера, сетевые зоны, типы взаимодействия - тогда волшебным образом получаешь классные замечания, инструкции и прочие радости
г) разбор сложносочиненных табличек и пдфок в саммари (так же не скупясь к описанию)
д) регламенты из сложносочиненных в человекопонятные
е) рутинные операции "преобразуй из вот этих экселек по примеру вот такую таблицу с такими колонками".
Пока все, но буду рад еще чему-то новому от сообщества
можно конкретные примеры, как ИИ может реально помочь в работе ПМа?
Мои кейсы весьма просты:
написать резюме встречи с основными выводами (о да, вместо часа на анализ больших встреч теперь это 15 минут, прогнать КТалковую расшифровку и выделить главные выводы. Экономия, ну может час в месяц
Документация и проектирование соединений - вот тут задать полные условия в тот же дипсик и получить классный документ - 30 минут вместо дня. Экономия 1-2чд в месяц
Анализ документов и создание выжимки/сводных данных - иногда ок, иногда глюки такие, что лучше руками делать - экономии не обнаружено
Составление планов интеграционного тестирования и инструкций - тут так же как в пункте 2 - при отсутствии в проекте тестера в большом количестве спаспет, при наличии - смысла нет, но денег и времени экономит так же 1-2чд в мес.
При отсутствии навыка писать хороший sql, при хорошем промте выдает нормальные сложные запросы, которые вешают базу))))
Рисовать очередного бесполезного ГАННТа или критические пути - я быстрее, чем промт и так скажу, что важно, а что бантик, и что минимально нужно сделать. Чтобы реально считало, надо отпуска и допущения так описывать, что быстрее самому показать.
Возможно, еще распределение задач на команду может делать исходя из уже наличествующих приоритетов и оценок. Но в целом это 15 минут работы, а подготовки к тому, чтобы этот процесс автоматизировался - днями.
Есть еще идеи или кейсы, или это опять популизм "ИИ все изменит", а по факту влажные фантазии всех не сильно далеких руководителей мира, готовых вваливать корп.бюджет в ИИ ради кейса в резюме, урезая людей и зарплаты, вместо того, чтобы осознать, что достаточно просто нанимать квалифицированные кадры за бОльший прайс и получать хороший результат, а не закрывать костылем с ИИ свою некомпетентность?
так сколько было людей в подчинении и сколько стало в вашем конкретном случае?))) Это, к слову, куда как более наглядная история, чем майки и сторипоинты. Я руководил командами на 40 и на 8 человек. Разница очень большая как раз в уровне вопросов, решаемых на уровне команды, а не руководителя. Трайбы там на 100 человек - так же другой шаг. Руководить всем ИТ - следующая ступенька и так далее. Каждая ступенька - определенный набор навыков для развития, и от вашего числа "тогда" и "сейчас" как раз станет понятно, а на каком уровне вы находитесь, для которого релевантны ваши советы. К примеру, для любого следующего уровня за 20 человек я бы посоветовал найти в первую очередь полного заместителя на случай атомной войны из коллег и растить его как замену, постепенно делегируя зоны ответственности. Это гарантирует отпуска и свободную голову. Для уровня 100+ в первую очередь я бы советовал вообще отказаться от деталей и лезть только в верхние метрики команд и сервисов, но зато делать это регулярно, чтобы иметь руку на пульсе и видеть взаимосвязи. Что там дальше - еще не знаю)
Для сертификатов и продлений давно придуманы системы учета единиц конфигурации, к которым применяются алерты и задания (продления/перенастройки и так далее) - если уж вручную делать, то не спустя 3ч, как ресурс упал, а за день-неделю до, как бы очевидно, что это бред просрачивать то, что нужно делать превентивно. Ну и для автообновления lets encrypt существуют процессы тоже, хотя если у вас простые хостинги, не своя инфра, то осязаемо-ожидаемо, что надо ручками.
Что касается больших проектов, то "я же говорила" - самый большой факап. ТЗ на бумаге, правки только по почте, фиксация только в учетной системе. Все чаты - это бег в угоду скорости до первого серьезного конфликта, зачем до них доводить? В закрепы ссылку на ресурс, в ресурсе никаких изменений, кроме ваших, ответственный вносит их только после аналитики и согласования изменившихся сроков/денег, а то можно на голову сесть. Так чат для оперативки, а договоренности менять дорого становится, приходится платить и думать заказчику, а не просто жить с рабами на галере.
у нас в Новосибе народ из МСК не понимает, как мы тут ездим, полос же нет нифига. Чтобы ИИ стал водить в таких условиях? Да нет, только люди могут, ИИ не вытерпит и уйдет на завод) Так что нескоро еще ИИ зайдет в эту нишу. В МСК да, больше нигде, как я вижу при таком отношении властей к инфраструктуре
потому что не надо путать время на задачу с ее объемом. Сторипоинт - это "сколько стоит задача", а не "когда она будет сделана" или "сколько времени нужно на выполнение". Планирование по сторипоинтам - это как линейкой мерить сопротивление, получается. Все статьи рассказывают, как переводить сторипоинты в часы (вернее, почему не надо этого делать), а речь про рубли мать его, и как только это осознаешь, перестаешь задавать себе глупый вопрос "почему не надо мерить сторипойинтами объем спринта в планировании".
Хочется план на спринт - измеряйте в часах задачи классически, где задача - это атомарная сущность на разработчика/тестировщика, и закладывайте время на другую работу, чтобы понять реальный объем времени людей над бэклогом (то есть из 8ч убрать 2ч прокрастинации и 2ч помощи саппорту, если оно не вынесено в отдельную задачу с лимитом, дейлики и прочие активности) - и вуаля, планирование начнет в среднем сходиться. В любом случае будут ошибки, но их доля в общем числе будет невелика.
В сторипоинты оставьте эпикам/фичам, потому что это мера полезности относительно других сущностей.
поверь, не эджайл появился, и все поменялось, а добрая половина примерно так и работала всегда, просто не было слова эджайл. Как в известной песне про попу, которая есть, а слова нет. И Королев с Хрущевым в том числе имели как элементы эджайла (планерки ежедневные на заводе, премии под конец месяца/итерации), квартальные и годовые планирования, переосмысления продуктов на ходу - чем блин не эджайл?
автор пишет о коне в вакууме. Типа я бы хотел делать что-то такое, уххх, крутое, уххх полезное, а вынужден пилить фичи для бизнеса, пользы которых он не видит (а на самом деле не понимает, считая всех вокруг двоечками, а себя белопальтовым десятком). Ничего конкретного, мыслею по древу, что все вокруг дурачки, ничего не понимают, а он Д'Артаньян, знает, что если просто инженерам дать делать что-то важное, то получится важное. Или получится что-то неважное, мы ж творческие люди, лишь бы никто не смотрел и не канал за это каждые 2 недели. Просто деньги заносить не забывайте. У меня коты так же думают, откровенно. Чел мог бы быть хорошим котом.
Ну и занимается натягиванием совы на глобус, дергая узкие факты, извращая и подменяя их смысл, а потом придумывая им ложные цели. Это касается его отсылок "почему так делается, и кто это придумал так жить". Большей манипулятивной оленистики давненько не читал.
Чувак, иди прогай свой фейсбук3Д, тебе уже за 30, ты десятка-альфа-миллиардер-и-филантроп, у тебя куча возможностей и по твоим словам скиллов, так хрен ли ты этого не сделал? Что за тезисы про реально полезные и нужные вещи (какие вещи? Конкретно хоть 1 назвал?).
Но мы не узнаем, потому что перевод копипасты нам не сможет ответить)
На деле в разных схемах поработал, и могу сказать, что нет, нормальный тех.руководитель над командой вполне отлично слушает и помогает выбирать различные задачи, в том числе развитийные без ловушки "делаем маленькое за 2 недели". В продуктах устоявшихся уж точно. В стартапах нет, там всегда четко понятно, как догнать и перегнать через 5 лет, и пилить в них и пилить до лидеров рынка те самые 5 лет.
Мне, как руководителю продуктов с навыками в системной архитектуре как раз понятно, как для ИИ описать и бизнес-смысл и ограничения, и как подать на вход корректную постановку, чтобы получить результат быстро. Но в любом случае, ИИ пока может собрать сервисы, а вот собрать из них процесс целиком, сохранить корп.дизайн, учесть ИБ, не забыть связку с фронтом, если это не просто бэковый сервис по перекладыванию JSON - нет, ИИ пока без человека не может. А вот закрывать саппорт и документацию, писать тесты на основе постановок быстро, автоматизировать регрессионное тестирование, готовить кейсы под функциональное, рисовать какие-то спрайты, генерировать модель для подсчета, решать смежные функции при отсутствии специалиста (тот же девопс), быстро подсказывать и наращивать компетенции - ИИ сможет. Это значит, что рынок вакансий (а жто уже происходит сейчас) сузится, и остановится рост ЗП в айти, станет дольше и труднее находить работу тем же джуниорам (кому они нужны, когда сеньоров уже много, а работу частично отдали ИИ) - и как бы выход только 1 - менеджменту придется брать больше продуктов и задач в единицу времени, чтобы сохранять штат и делать больше, причем успешных продуктов, и вот тут ИИ тоже может помочь с анализом рынков, с построением фин.моделей и планов маркетинга, с прогнозированием интересных решений
Это та же самая разница, что и между весом и массой в физике. Часы - это масса. Часы, оцененные в задаче, это субъективные часы одного разработчика, а ведь есть еще менеджмент, его часы другие, есть тестирование, есть код-ревью, есть работа аналитика, есть работа сопровождения, и стоимость каждого часа разная, и сравнивать задачи по сумме часов не имеет смысла, ведь тогда надо нормировать общие часы предварительно на таблицу коэффициентов. Тогда есть смысл оценивать уж в деньгах, как универсальной валютой меры измерений задачи. А сторипоинт - это вес. С какой силой задача давит на бэклог))) Проще для оценки, но суть та же самая - в конце ты получаешь стоимостную оценку. Но ведь команда не только делает задачи, но еще и ходит на дэйли, обсуждает задачи, имеет какие-то активности вне задач со своими линейными руководителями и так далее. Как следствие, измерение денег в задаче должно считаться с коэффициентом утилизации 8ч сотрудника аля "х2". Сторипоинт же нивелирует все эти ограничения заранее - просто мера неясного генеза, где эмпирически за полгода можно примерно понимать и стоимость 1сп и не держать в голове вот эти таблицы пересчета на часики.
Главное не превращать инструмент измерения в ОКР/KPI, а руководителей, не знакомых с этим принципом, не допускать до управления. Потому что ровно в тот момент, когда ты вместо критерия получаешь цель, начинаются манипуляции с данными, дробление задач и так далее. Та же история, к слову, с T2m (time 2 market). Когда вместо выпуска функциональности команда ради хороших зарплат начинает фичерить и декомпозировать функциональности так, чтобы быстро их показывать, но приносить этими маленькими выпусками по факту ровно 0 пользы (зачем тебе задача со спрограммированной кнопкой умножить в калькуляторе, когда тебе нужен весь калькулятор). Поэтому цель - всегда бизнесовая, метрика - всегда бизнесовая в профит/лосс
Извините, но почему такие метрики бизнеса надо сложно мониторить в графане+прометеусе? Для базовой аналитики (уж типа dau/mau) есть же для веба Яндекс-метрика/ГА, для мобилок appmetrika+firebase? Я бы сказал, что это основа основ для коммерческих приложений. Для закрытых сегментов сети да, надо ставить тогда сервера matomo, тут реально иногда проще в графану запихаться, но во всех остальных случаях все выкаты регулируются именно типовыми стандартными приложухами. Для когорт - amplitude удобнее всего, хотя и GA уже это все позволяет. Для внутренних обработок я вообще предпочитаю логгирующие таблицы в БД класть, потому что дашборды дашбордами, кибана кибаной, а разбор отклонений все равно sql-кой удобнее делать)
А как вы growth-задачи на таком подходе вообще можете отловить? Как выстроена работа не по фичам, а по платящей аудитории и из потребности не на основе отзывов, а на основе того же jtbd, например? Или это описана работа support-team с классическим канбаном, все же продукт зрелый, а в growth не заморачиваетесь почти вообще или он вынесен в отдельный стрим со своими процессами и подходами к исследованиям?
Ну так соберите всю доступную информацию быстрее, чем это сделает нейросеть. Речь же не идет о замене, там в тексте прямо написано, что это не заменит реального интервью, но когда это интервью все не получается, то на безрыбье и рак рыба. Галлюцинации сети в этом случае хотя бы обусловлены чем-то, а галюны продакта, который плодит гипотезы из головы - ничем
Так вы и описали классический сервис, а не микросервис. Зачем вы их уменьшаете в повествовании - непонятно. У вас стоял выбор - написать цельный сервис с компонентами внутри или написать набор микросервисов в цепочке. Вы против микросервисов, и за SOA, говорите своими именами просто и все.
Проблематика SOA по цепочке взаимодействий и иногда "вкруг два раза" - это проблема не сервисного подхода как класса решения, а архитектурной импотентности в компании, у SOA-подхода нет такого минуса, это частный случай легаси. Не спроектировали, как и где будут лежать данные и протоколы их получения вовремя или не занялись причесыванием архитектуры - получили что получили
что я щас прочитал вообще: задачи накидали в итерацию по приницпу "и так сойдет", не было грумминга, предварительной оценки и планирования (где на каждого сначала смотрится наличие свободного времени, а потом планируется не под шапочку, а с небольшим запасом), и потом не было ежедневных стендапов, где каждый если что говорит, если перевел задачу в ожидание, и что от кого ждет.
Чтобы избавиться от всех вышеописанных проблем в зародыше, требуется всего лишь планировать людей на итерацию и ежедневно с утра командой синкаться. И тогда все эти фильтры не нужны, ведь они вынесены на стадии на доске, и по ним ответственный сотрудник должен будет рассказать.
как бывший игрок в покер очень многое переосмыслил в работе, как раз начав применять "дистанция все вернет" (не вернет) и "результат - лишь следствие правильно принятых решений". Вероятностный подход прекрасен, но не стоит забывать и о дисперсии, особенно в высокорисковых решениях - та самая дистанция может не успеть вернуть, и всегда важно оглядываться и иногда принимать неоптимальные, но более стабильные решения ради будущих возможностей. Вода водой, конечно, но когда ты начинаешь думать не решением, а спектром решений, по сути переходишь от уровня принятия решения к уровню принятия стратегии, сразу меняется взгляд на бизнес и карьеру
Добро пожаловать в бизнес-анализ. Системная аналитика как обычно ни при чем)
Работой системного аналитика было бы писать в отдельную таблицу акционные убытки, чтобы потом бизнес-аналитику можно было простым селектом сделать выборку из этой таблицы без заморочек со сложносочиненным sql) Хотя навык безусловно не лишний. В своей практике так же при разборе проблем с БД использую ИИ для помощи в написании sql, но мы оптимизировали с рарзработкой сбор данных в бд так, чтобы с ним можно было поэтапно отработать и возрадоваться наиболее быстрым способом
нет, я закидываю документ, формат ожидаемого ответа, и получаю что-то. У системы просто не хватает пласта данных, как и у меня на старте, так что путь тут просто закрыт. Легаси, плохая документированность и прочие радости, все как руками, нет тут вины ИИ, есть проблема, что этот класс задач не решаем на текущем уровне, но даже так ИИ предусматривает больше, чем миддл-аналитик и тестер уже сейчас, это подкупает
я не каждый день играю в системного архитектора. Проекты не длятся 2-4 дня, это месяцы разработки, поэтому ежедневно нет смысла. Речь про реальный сектор, производственные и торговые блоки на предприятиях с оборотом как ВВП моей области, если не целой страны. Поэтому да, проще загнать условия и получить черновик схемы раз, а потом уже команда и арх.комитет уточняет
тут дело в том, что ИИшница встроена в ТОЛК. Ваще ниче не надо, кроме причесать. Но отдать непричесанный вариант тоже можно без флоу и попросить саммари по саммари (надо увидеть раз Толковые расшифровки, чтобы понять, о чем я, там просто блоки почти дублируются местами, и их приходится разделять). Но делать еще и флоу не хочется, попробую загонять результат ИИ в еще один ИИ, быстрее будет)
Привет.
А поделитесь своими кейсами использования ИИ в проектном менеджменте? Практическими, что и как хочется получать, что делаете, какими ИИ пользуетесь. Я начну)
2 месяца назад пошел в Дипсик. Использую для:
а) написании сложных для меня sql-ек
б) разборе логов по предусловиям (условия и логику обозначаю - получаю возможные проблемы или точки отказа)
в) подготовке проектной документации и особенно тестирования на основе функ.требований/постановки. Главное, не скупиться на буквы и с параметрами и четкими обозначениями определять в промте таблицы БД, сервисы, сервера, сетевые зоны, типы взаимодействия - тогда волшебным образом получаешь классные замечания, инструкции и прочие радости
г) разбор сложносочиненных табличек и пдфок в саммари (так же не скупясь к описанию)
д) регламенты из сложносочиненных в человекопонятные
е) рутинные операции "преобразуй из вот этих экселек по примеру вот такую таблицу с такими колонками".
Пока все, но буду рад еще чему-то новому от сообщества
можно конкретные примеры, как ИИ может реально помочь в работе ПМа?
Мои кейсы весьма просты:
написать резюме встречи с основными выводами (о да, вместо часа на анализ больших встреч теперь это 15 минут, прогнать КТалковую расшифровку и выделить главные выводы. Экономия, ну может час в месяц
Документация и проектирование соединений - вот тут задать полные условия в тот же дипсик и получить классный документ - 30 минут вместо дня. Экономия 1-2чд в месяц
Анализ документов и создание выжимки/сводных данных - иногда ок, иногда глюки такие, что лучше руками делать - экономии не обнаружено
Составление планов интеграционного тестирования и инструкций - тут так же как в пункте 2 - при отсутствии в проекте тестера в большом количестве спаспет, при наличии - смысла нет, но денег и времени экономит так же 1-2чд в мес.
При отсутствии навыка писать хороший sql, при хорошем промте выдает нормальные сложные запросы, которые вешают базу))))
Рисовать очередного бесполезного ГАННТа или критические пути - я быстрее, чем промт и так скажу, что важно, а что бантик, и что минимально нужно сделать. Чтобы реально считало, надо отпуска и допущения так описывать, что быстрее самому показать.
Возможно, еще распределение задач на команду может делать исходя из уже наличествующих приоритетов и оценок. Но в целом это 15 минут работы, а подготовки к тому, чтобы этот процесс автоматизировался - днями.
Есть еще идеи или кейсы, или это опять популизм "ИИ все изменит", а по факту влажные фантазии всех не сильно далеких руководителей мира, готовых вваливать корп.бюджет в ИИ ради кейса в резюме, урезая людей и зарплаты, вместо того, чтобы осознать, что достаточно просто нанимать квалифицированные кадры за бОльший прайс и получать хороший результат, а не закрывать костылем с ИИ свою некомпетентность?
так сколько было людей в подчинении и сколько стало в вашем конкретном случае?))) Это, к слову, куда как более наглядная история, чем майки и сторипоинты. Я руководил командами на 40 и на 8 человек. Разница очень большая как раз в уровне вопросов, решаемых на уровне команды, а не руководителя. Трайбы там на 100 человек - так же другой шаг. Руководить всем ИТ - следующая ступенька и так далее. Каждая ступенька - определенный набор навыков для развития, и от вашего числа "тогда" и "сейчас" как раз станет понятно, а на каком уровне вы находитесь, для которого релевантны ваши советы. К примеру, для любого следующего уровня за 20 человек я бы посоветовал найти в первую очередь полного заместителя на случай атомной войны из коллег и растить его как замену, постепенно делегируя зоны ответственности. Это гарантирует отпуска и свободную голову. Для уровня 100+ в первую очередь я бы советовал вообще отказаться от деталей и лезть только в верхние метрики команд и сервисов, но зато делать это регулярно, чтобы иметь руку на пульсе и видеть взаимосвязи. Что там дальше - еще не знаю)
Для сертификатов и продлений давно придуманы системы учета единиц конфигурации, к которым применяются алерты и задания (продления/перенастройки и так далее) - если уж вручную делать, то не спустя 3ч, как ресурс упал, а за день-неделю до, как бы очевидно, что это бред просрачивать то, что нужно делать превентивно. Ну и для автообновления lets encrypt существуют процессы тоже, хотя если у вас простые хостинги, не своя инфра, то осязаемо-ожидаемо, что надо ручками.
Что касается больших проектов, то "я же говорила" - самый большой факап. ТЗ на бумаге, правки только по почте, фиксация только в учетной системе. Все чаты - это бег в угоду скорости до первого серьезного конфликта, зачем до них доводить? В закрепы ссылку на ресурс, в ресурсе никаких изменений, кроме ваших, ответственный вносит их только после аналитики и согласования изменившихся сроков/денег, а то можно на голову сесть. Так чат для оперативки, а договоренности менять дорого становится, приходится платить и думать заказчику, а не просто жить с рабами на галере.
у нас в Новосибе народ из МСК не понимает, как мы тут ездим, полос же нет нифига. Чтобы ИИ стал водить в таких условиях? Да нет, только люди могут, ИИ не вытерпит и уйдет на завод) Так что нескоро еще ИИ зайдет в эту нишу. В МСК да, больше нигде, как я вижу при таком отношении властей к инфраструктуре
потому что не надо путать время на задачу с ее объемом. Сторипоинт - это "сколько стоит задача", а не "когда она будет сделана" или "сколько времени нужно на выполнение". Планирование по сторипоинтам - это как линейкой мерить сопротивление, получается. Все статьи рассказывают, как переводить сторипоинты в часы (вернее, почему не надо этого делать), а речь про рубли мать его, и как только это осознаешь, перестаешь задавать себе глупый вопрос "почему не надо мерить сторипойинтами объем спринта в планировании".
Хочется план на спринт - измеряйте в часах задачи классически, где задача - это атомарная сущность на разработчика/тестировщика, и закладывайте время на другую работу, чтобы понять реальный объем времени людей над бэклогом (то есть из 8ч убрать 2ч прокрастинации и 2ч помощи саппорту, если оно не вынесено в отдельную задачу с лимитом, дейлики и прочие активности) - и вуаля, планирование начнет в среднем сходиться. В любом случае будут ошибки, но их доля в общем числе будет невелика.
В сторипоинты оставьте эпикам/фичам, потому что это мера полезности относительно других сущностей.
поверь, не эджайл появился, и все поменялось, а добрая половина примерно так и работала всегда, просто не было слова эджайл. Как в известной песне про попу, которая есть, а слова нет. И Королев с Хрущевым в том числе имели как элементы эджайла (планерки ежедневные на заводе, премии под конец месяца/итерации), квартальные и годовые планирования, переосмысления продуктов на ходу - чем блин не эджайл?
автор пишет о коне в вакууме. Типа я бы хотел делать что-то такое, уххх, крутое, уххх полезное, а вынужден пилить фичи для бизнеса, пользы которых он не видит (а на самом деле не понимает, считая всех вокруг двоечками, а себя белопальтовым десятком). Ничего конкретного, мыслею по древу, что все вокруг дурачки, ничего не понимают, а он Д'Артаньян, знает, что если просто инженерам дать делать что-то важное, то получится важное. Или получится что-то неважное, мы ж творческие люди, лишь бы никто не смотрел и не канал за это каждые 2 недели. Просто деньги заносить не забывайте. У меня коты так же думают, откровенно. Чел мог бы быть хорошим котом.
Ну и занимается натягиванием совы на глобус, дергая узкие факты, извращая и подменяя их смысл, а потом придумывая им ложные цели. Это касается его отсылок "почему так делается, и кто это придумал так жить". Большей манипулятивной оленистики давненько не читал.
Чувак, иди прогай свой фейсбук3Д, тебе уже за 30, ты десятка-альфа-миллиардер-и-филантроп, у тебя куча возможностей и по твоим словам скиллов, так хрен ли ты этого не сделал? Что за тезисы про реально полезные и нужные вещи (какие вещи? Конкретно хоть 1 назвал?).
Но мы не узнаем, потому что перевод копипасты нам не сможет ответить)
На деле в разных схемах поработал, и могу сказать, что нет, нормальный тех.руководитель над командой вполне отлично слушает и помогает выбирать различные задачи, в том числе развитийные без ловушки "делаем маленькое за 2 недели". В продуктах устоявшихся уж точно. В стартапах нет, там всегда четко понятно, как догнать и перегнать через 5 лет, и пилить в них и пилить до лидеров рынка те самые 5 лет.
Мне, как руководителю продуктов с навыками в системной архитектуре как раз понятно, как для ИИ описать и бизнес-смысл и ограничения, и как подать на вход корректную постановку, чтобы получить результат быстро. Но в любом случае, ИИ пока может собрать сервисы, а вот собрать из них процесс целиком, сохранить корп.дизайн, учесть ИБ, не забыть связку с фронтом, если это не просто бэковый сервис по перекладыванию JSON - нет, ИИ пока без человека не может. А вот закрывать саппорт и документацию, писать тесты на основе постановок быстро, автоматизировать регрессионное тестирование, готовить кейсы под функциональное, рисовать какие-то спрайты, генерировать модель для подсчета, решать смежные функции при отсутствии специалиста (тот же девопс), быстро подсказывать и наращивать компетенции - ИИ сможет. Это значит, что рынок вакансий (а жто уже происходит сейчас) сузится, и остановится рост ЗП в айти, станет дольше и труднее находить работу тем же джуниорам (кому они нужны, когда сеньоров уже много, а работу частично отдали ИИ) - и как бы выход только 1 - менеджменту придется брать больше продуктов и задач в единицу времени, чтобы сохранять штат и делать больше, причем успешных продуктов, и вот тут ИИ тоже может помочь с анализом рынков, с построением фин.моделей и планов маркетинга, с прогнозированием интересных решений
Это та же самая разница, что и между весом и массой в физике. Часы - это масса. Часы, оцененные в задаче, это субъективные часы одного разработчика, а ведь есть еще менеджмент, его часы другие, есть тестирование, есть код-ревью, есть работа аналитика, есть работа сопровождения, и стоимость каждого часа разная, и сравнивать задачи по сумме часов не имеет смысла, ведь тогда надо нормировать общие часы предварительно на таблицу коэффициентов. Тогда есть смысл оценивать уж в деньгах, как универсальной валютой меры измерений задачи. А сторипоинт - это вес. С какой силой задача давит на бэклог))) Проще для оценки, но суть та же самая - в конце ты получаешь стоимостную оценку. Но ведь команда не только делает задачи, но еще и ходит на дэйли, обсуждает задачи, имеет какие-то активности вне задач со своими линейными руководителями и так далее. Как следствие, измерение денег в задаче должно считаться с коэффициентом утилизации 8ч сотрудника аля "х2". Сторипоинт же нивелирует все эти ограничения заранее - просто мера неясного генеза, где эмпирически за полгода можно примерно понимать и стоимость 1сп и не держать в голове вот эти таблицы пересчета на часики.
Главное не превращать инструмент измерения в ОКР/KPI, а руководителей, не знакомых с этим принципом, не допускать до управления. Потому что ровно в тот момент, когда ты вместо критерия получаешь цель, начинаются манипуляции с данными, дробление задач и так далее. Та же история, к слову, с T2m (time 2 market). Когда вместо выпуска функциональности команда ради хороших зарплат начинает фичерить и декомпозировать функциональности так, чтобы быстро их показывать, но приносить этими маленькими выпусками по факту ровно 0 пользы (зачем тебе задача со спрограммированной кнопкой умножить в калькуляторе, когда тебе нужен весь калькулятор). Поэтому цель - всегда бизнесовая, метрика - всегда бизнесовая в профит/лосс
Извините, но почему такие метрики бизнеса надо сложно мониторить в графане+прометеусе? Для базовой аналитики (уж типа dau/mau) есть же для веба Яндекс-метрика/ГА, для мобилок appmetrika+firebase? Я бы сказал, что это основа основ для коммерческих приложений. Для закрытых сегментов сети да, надо ставить тогда сервера matomo, тут реально иногда проще в графану запихаться, но во всех остальных случаях все выкаты регулируются именно типовыми стандартными приложухами. Для когорт - amplitude удобнее всего, хотя и GA уже это все позволяет. Для внутренних обработок я вообще предпочитаю логгирующие таблицы в БД класть, потому что дашборды дашбордами, кибана кибаной, а разбор отклонений все равно sql-кой удобнее делать)
А как вы growth-задачи на таком подходе вообще можете отловить? Как выстроена работа не по фичам, а по платящей аудитории и из потребности не на основе отзывов, а на основе того же jtbd, например? Или это описана работа support-team с классическим канбаном, все же продукт зрелый, а в growth не заморачиваетесь почти вообще или он вынесен в отдельный стрим со своими процессами и подходами к исследованиям?
Ну так соберите всю доступную информацию быстрее, чем это сделает нейросеть. Речь же не идет о замене, там в тексте прямо написано, что это не заменит реального интервью, но когда это интервью все не получается, то на безрыбье и рак рыба. Галлюцинации сети в этом случае хотя бы обусловлены чем-то, а галюны продакта, который плодит гипотезы из головы - ничем
Так вы и описали классический сервис, а не микросервис. Зачем вы их уменьшаете в повествовании - непонятно. У вас стоял выбор - написать цельный сервис с компонентами внутри или написать набор микросервисов в цепочке. Вы против микросервисов, и за SOA, говорите своими именами просто и все.
Проблематика SOA по цепочке взаимодействий и иногда "вкруг два раза" - это проблема не сервисного подхода как класса решения, а архитектурной импотентности в компании, у SOA-подхода нет такого минуса, это частный случай легаси. Не спроектировали, как и где будут лежать данные и протоколы их получения вовремя или не занялись причесыванием архитектуры - получили что получили