У меня есть отдельная папочка для подобных статей - куда я складываю материалы, которые как-будто приоткрывают волшебную дверь в заколдованный мир. Такое ощущение у меня в детстве было от книг Мартина Гарднера - потому что все эти пентамино, гексафлексагоны и прочие додекаэдра ну никак не вписать в реальную жизнь - но они настолько доступно и интересно преподнесены, настолько неожиданные и красивые свойства их подсвечены и настолько далёкая от тебя сфера применения описана, что ты читаешь это как захватывающий роман.
Спасибо! Очень приятная статья для вечера пятницы!
(Кстати, если кто-то захочет почитать ещё чего-то подобного на ночь глядя, то вот вам отличный вариант ?)
Взаимное соответствие работает только для счетных множеств - а множество точек на отрезке не является счетным, т.к. отрезок не состоит из точек, это непрерывная сущность.
И автор пытается счетным (пусть и бесконечным) числом стрелочек от одного отрезка к другому пересчитать несчётное множество иррациональных точек на отрезке - что невозможно, согласно диагональному аргументу Кантора.
Вы просто слишком умные ? Судя по описанию, вы звоните в колл-центр уже проанализировав проблему и найдя вариант решения - и вам нужно лишь запустить в работу этот вариант.
Поверьте, подавляющее большинство людей, которые звонят в колл-центры, порой даже не в состоянии сформулировать проблему. А когда формулируют - оказывается, что это проблема из разряда "убедитесь, что компьютер включен".
Ну например. Пенсионерка звонит своему внуку и не дозванивается, слышит странное пиликанье в трубке. Она тут же начинает звонить в поддержку - и если ей ответит оператор, то ему придется выслушивать невнятную историю о том, как бабуля ему каждый день звонит - а теперь дозвониться не может, а возможно с ним что-то случилось, а вот при Сталине телефоны нормально работали и не то что сейчас, а позовите мне самого главного начальника а не этого молодого мальчика...и т.п.
А у неё просто деньги закончились на телефоне - вот и всё ? и зачем ей оператор? Робот сразу ей сам это скажет. И основной поток звонков именно так и отсекается. И именно поэтому роботы и задают такие тупые вопросы при попытке переключиться на кожаного.
А у всяких экстренных контор - аварийные страховые, потеря карты в банке и т.п. - всегда есть отдельный прямой номер для разговора с кожаным мешком в экстренной ситуации.
Ну вы, в целом, просто переназвали классические GTDшные статусы: PLAN/DO/FOLLOWUP/POSTPONE/DONE. Никто ещё не придумал никакой замены им, все задачи в мире устроены одинаково.
У всех людей мозг устроен по-разному - кто-то может сотню заметок свалить в кучу и помнить каждую - а кто-то не уснет, пока не разложит заметки по тегам, папкам, приоритетам и цветам.
Так что не надо ругать Лумана и Арненса, или называть извращенцами любителей Цеттеля - они не больше вас извращенцы, просто им так удобнее. Главное чтобы задача решалась.
Стоит упомянуть что самые "странные" это как раз "A" сэмплеры. С ними генерация за 20 шагов может очень сильно отличаться от генерации за 19 при одном и том же сиде, что исключает их использование в некоторых сценариях
Ancestral-сэмплеры не странные. Они просто добавляют в генерацию немного шума на каждом шаге. Это позволяет чуть ускорить генерацию, но по определению не позволяет получить стабильно воспроизводимый результат с одними и теми же входными параметрами.
Забавно то, что полученные якобы с помощью ТРИЗ решения проблем всё равно прямолинейные и самоочевидные. Типа такого:
Сделай заранее. Как проинформировать пользователя о возможностях навыка до его запуска? Например, выпустить небольшое промо‑видео или расписать функции на странице навыка
Используй элементы другого типа. Вместо того, чтобы использовать голос, вывести на экран карточку со списком доступных функций и примерами команд
И так далее. Это кстати традиционная боль российских "брейнштормов" - когда собирается толпа умных людей для креативного решения вопроса "Как нам повысить продажи", сидит пять часов не вставая, пишет на карточках странные рецепты из Бьюзена, Микалко и Альтшуллера - и по итогу, с гордым видом, выдает решения, в духе "надо делать больше рекламы" и "надо использовать телеграм, а не смски".
Так и тут - программисты натянули сову своих галлюцинаций относительно пользовательских сценариев на металлопрокатный глобус альтшуллера и получили рецепт в духе "надо показывать рекламу побольше и более короткими отрезками".
А меж тем вам надо было бы всего лишь, например, взять РЕАЛЬНЫХ детей и в каких-то реалистичных условиях смоделировать с ними то, как они будут спрашивать домашку у друга или у учителя. И в каком формате они будут ожидать ответ - ибо очевидно, что дробление домашки на мелкие кусочки и выдавание их порциями забесит ребенка на третьем шаге - и он психанет, скажет: "Алиса, ты какая-то слишком тупая, не можешь мне нормально сказать, чо нам задали!" и не вернётся к ней с этим вопросом больше никогда.
Короче, сценарии надо строить от реального CJM, а не от кабинетных брейнштормов. И вот уже в РЕАЛЬНЫХ сценариях будут настоящие противоречия, на решение которых и заточен ТРИЗ (а не на вымышленные вами самими противоречия). Типа - ребенку надо детально рассказать про домашку, но слушать спич длиннее восьми секунд он физически не может. И вот для этого надо будет придумывать уже НЕОБЫЧНЫЕ методы с помощью брейнштормов и фреймворков для них.
А для подобных очевидных решений в духе "разбить на части" и "сделать заранее" - это вы можете свой YaGPT попросить, он как раз такие ответы и выдает.
Краткий пересказ статьи: выгружаете список задач, считаете сколько сделано/не сделано/зависло/и т.п., строите из этого столбики в Экселе и столбики красите в запрещённые радужные цвета. А дальше вам почему-то станет легче управлять командой - но непонятно почему.
Всё.
Ах, да, надо еще назвать это квантово-волновой диаграммой. Ну потому что у нас квантовые задачи - то ли сделаны, то ли нет - не поймёшь. Логично же. Поэтому ревью задач мы будем называть "квантовые вычисления" - ну типа мы же там вычисляем, какие задачи делать.
Вот действительно странно: статья типа для начинающих и без математики - но ни эмбеддинг, ни даже токен не объясняются как понятия... А дальше по тексту всё равно начинается вот такое:
Этот механизм можно представить как метод, который заменяет каждый эмбеддинг токена на эмбеддинг, содержащий информацию о соседних токенах, вместо использования одинакового эмбеддинга для каждого токена вне зависимости от контекста.
Это же прям классика из "продвинутых" учебников, где тебе говорят: "Щас мы вам объясним понятие предела на пальцах!!! Вот смотрите - существует такой эпсилон, который больше нуля, да ещё и такой, что при каждом сигма (тоже большем нуля), равном эпсилон-итому, каждый сигма минус эпсилон по модулю меньше дельта! Вот так всё просто! Итак, продолжаем..."?♂️
Очень хорошо! Ёмко и по делу! Ещё бы хотелось почитать, как на практике бороться с этими искажениями. Например, для предотвращения амплификации, ставить ограничение по времени на обдумывание задачи - чтобы люди не залипали и начинали работу с какими-то промежуточными данными на входе.
Два раза прочитал и так и не понял, в чем прикол. Они просто перенесли закон Дарвина на всё вокруг. Типа: надёжно статичное остаётся; гибкое и динамичное - меняется; а если есть опция чот выкинуть радикально новое - ну, так оно и выкинется. И дальше по этой же цепочке отомрет или разовьётся.
Но у этих изменений нет цели, и даже какой-то прогнозируемости или расчетности - как у закона сохранения энергии, который, в этом смысле, именно што закон. То есть мы не можем посчитать, в какую сторону изменится кристалл или там звезда - не учитывая мириады мелких и непостижимых параметров окружающей действительности. А учесть мы их не сможем никогда.
В итоге, весь этот закон сводится к центральной предельной теореме из второкурсного тервера: если объединить вместе несколько абсолютно независимых событий с любыми распределениями, то получится гаусс. То есть если рандомно сыпать песочек, то где-то обязательно получится кучка. Если рандомно смешивать химические элементы - то получится молекула. Это мы знаем точно. Но мы никогда не сможем посчитать - где, когда и какая.
Такие проекты надо начинать с CJM, с пути пользователя и с точками на этом пути. И очень быстро станет ясно, что этих точек не так много - ровно столько, сколько есть врачей общей практики в поликлинике. И то, по каким сценариям работают эти врачи. А врачей не так то и много и они легко разделяются одним простым вопросом: "<Болит горло - к лору, болит нога - к хирургу, болит голова - к неврологу". И нет смысла пытаться определить, фарингит у него или ларингит - всё равно врач будет осматривать заново на месте и писать свой диагноз, а не ориентироваться на то, что там человек накликал в чат-боте. Детали диагноза человек всё равно сам не опишет - ну болит у него спина, тут без специалиста не понять - мышечный это спазм, нервный или ушиб какой. Тут всё равно терапевт нужен. А прийти к хирургу с нервной болью, чтобы он молча перенаправил тебя к неврологу - это уже потеря ожидаемой экономии на осмотре. То есть вся инновационная идея ИИ разобьётся о то, как законодательно регламентирована медицинская деятельность и как работают врачи в реальности.
Примерно, но не так радикально :) Грань - это рамки бизнес-модели, в которых существует продукт. А бизнес-модель - это не только разработка. Это, в первую очередь, стабильность и предсказуемость результатов при понятном формате взаимодействия и в понятном формате экономики.
В этом смысле, хаотичное допиливание и заваливание итшников рандомными задачами - вполне себе допустимая модель, подавляющее большинство бизнесов прекрасно в ней работает десятки лет. Она приятная для топов с их ЧСВ, она понятная для коммерсов и их коротким горизонтом планирования, она приемлема для акционеров с их совковым видением развития бизнеса в духе "бери больше кидай дальше, от забора и до обеда". Аргументы итшников в этом раскладе просто не будут услышаны, ИТ в данной ситуации - не драйвер бизнеса, а обслуживающее подразделение.
Переход к продукту происходит тогда, когда бизнес осознает, что продукт - это не просто спринты и релизы, а это стабильность развития функционала, гарантия его работоспособности и прогнозируемые затраты на получение понятного результата. Но запрос на такую стабилизацию экономики и прогнозируемость результата должен прийти от тех самых истеричных маркетологов - у которых должна, для этого, появиться стратегия и они должны научиться по ней работать, а не просто класть её в стол. Где-то тут должно появится понимание, что ИТ - это не просто мальчики на побегушках, а бизнес-критичный ресурс, от слаженной работы которого зависит получение коммерческого результата. А значит - итшников нельзя кошмарить лишний раз, нельзя заваливать задачами и отвлекать от работы, нельзя экономить на их штате и т.п. Тогда и начинается серьезный разговор и переход к продуктовым форматам.
Понятно, что и в этих форматах бывает бардак - продукты тоже, порой, допиливаются на бегу и скрам-команды иногда тушат пожары и работают в две смены. Но в данной ситуации это будет скорее исключение, чем правило - а значит не приведет к выгоранию и развалу команды, остановке разработки и, как следствие, остановки в развитии бизнеса.
У меня и на тему данной статьи есть прям кейсик описанный (ну как описанный - в телеге описанный для чатика ?), который отлично иллюстрирует все управленческие взаимодействия, которые в данном вопросе возникают. С вашей подачи я даже подумал, что это можно и в статью положить! Займусь, пожалуй, в ближайший день защитника отечества ?
Сорри, я чота нажимаю и оно исчезает, поэтому пишу три камента ?
Это всё строго загоняется в таск-трекер, все загрузки считаются, под коммуникацию с коммерсами выстраивается управленческая методология, ответственность за которую перекладывается на ГД, а не на ИТ. Ну т.е. если ИТ завернуло задачу от маркетологички - то это значит, что маркетологичка не бежит в ГД и не обкладывает ху@ми итшников - а идёт на проектный комитет и сама защищает приоритетность своей задачи в обществе таких же крикливых коммерсов, как она - а на ИТ выносится только финальный список договоренностей между коммерсами. К слову сказать, этот подход довольно быстро сбивает спесь с бизнес-заказчиков - т.к. орать на беззащитного итшника это не то же самое, что орать на коммерческого директора ?
В общем, этой длинной телегой я попытался ответить на ваш вопрос - а где грань?
Грань можно понять, когда разделите разные по формату задачи разработки, поддержки и развития и наложите их на текущий управленческий статус-кво - для понимания того, что из этого реально нужно бизнесу. Звучит сложновато, но в реальности - довольно просто проектируется, зато отвечает на кучу вопросов сразу
То есть вся эта история с разными типами продуктовых команд и спринтов, это в первую очередь история про разрыв в управленческих компетенций между коммерсами и ИТ. И исправлять начинать надо именно оттуда.
Приведу пример - вот буквально три месяца назад ко мне обратилась ИТ-команда из сложного большого ритейла ровно с таким же вопросом: как разнести техпод и разработку и как сделать так, чтобы генеральный не считал нас мудаками?
Про это можно отдельную статью писать, конечно, там много всего фундаментального. Но если вкратце - я им предложил разнести их работу на три разных сценария с разными SLA:
Техпод - это быстрые короткие задачи от которых зависит выживание бизнеса. Сиюминутное реагирование, высший приоритет - но список задач ограничен
Хотелки - это реализация хотелок бизнеса, но через призму оценки трудоемкости, жёстких приоритетов и четких SLA: сказали через месяц - значит получите через месяц и не орите ?
R&D - это четкий процесс долгосрочного развития систем, а также реализации хотелок, которые на первый взгляд были "изи", а как копнули - то стали "так блэт". Тут уже свои, очень длинные, сроки и другой формат взаимодействия с заказчиком
А это зависит, опять же, от бизнес-задачи, страт.планирования и управленческой силы ИТ. Потому что поддержка и разработка различаются, в первую очередь, с точки зрения бизнес-процессов и их параметров: преимуществ, производительности, прямых затрат и затрат косвенных (например, усилий, требующихся чтобы убедить два десятка пузатых директоров в том, что ИТ - это не помойка для их гениальных идей, а четкий механизм, работающий по своим правилам)
Вот смотрите. Спринт - он для чего нужен? Если просто - то для того, чтобы продукт выходил вовремя и без косяков, а также - чтобы разрабы не зашивались и не рвали волосы, метаясь между потоком задач от орущих маркетологов. А далее вопрос - а самим маркетологам это нужно? Как правило - им плевать на план и регулярность, им надо ad hoc - потому что так работает вся компания.
И даже если на словах ИТ-директор может договориться с генералом о том, что "спринт - это важно, стратегия - это важно, давайте придерживаться и т.п." - то закончится это тем, что генерал всё равно потом придет и скажет: "Ладно, пацаны, ну чо вы со своими спринтами - ну сделайте вы уже фичи этим маркетологичкам, у них же клиенты там, бизнес, продажи..."
Всё, значит стратегия не работает на самом высоком уровне. И значит, что для всей компании сиюминутное реагирование и тушение пожаров приоритетнее, чем планомерное движение к цели. Ок, это ни плохо, ни хорошо - это просто статус-кво. Просто этот статус-кво не бьётся с желанием ИТ делать всё системно. И аргументы типа: "У меня команда выгорает от неравномерной загрузки задачами, постоянного негатива от коммерсов и постоянно вчерашних дедлайнов!!" - эти аргументы не волнуют генерального. Ему плевать, что там с командой - ему важно, чтобы выдерживался привычный ему стиль работы: приказ отдал, побежали выполнять без вопросов. Что ж, такова данность и дальше надо думать, как в рамках нее существовать - есть ли у вас влияние, чтобы убедить генерального? Есть ли у вас полномочия, чтобы отказывать коммерсам? Есть ли у компании ресурсы, чтобы дать вам правильного объема команду? Есть ли вообще хоть у кого-то понимание, куда он идёт - и как это положить на ваш план? ?
У меня есть отдельная папочка для подобных статей - куда я складываю материалы, которые как-будто приоткрывают волшебную дверь в заколдованный мир. Такое ощущение у меня в детстве было от книг Мартина Гарднера - потому что все эти пентамино, гексафлексагоны и прочие додекаэдра ну никак не вписать в реальную жизнь - но они настолько доступно и интересно преподнесены, настолько неожиданные и красивые свойства их подсвечены и настолько далёкая от тебя сфера применения описана, что ты читаешь это как захватывающий роман.
Спасибо! Очень приятная статья для вечера пятницы!
(Кстати, если кто-то захочет почитать ещё чего-то подобного на ночь глядя, то вот вам отличный вариант ?)
Да всё элементарно.
Взаимное соответствие работает только для счетных множеств - а множество точек на отрезке не является счетным, т.к. отрезок не состоит из точек, это непрерывная сущность.
И автор пытается счетным (пусть и бесконечным) числом стрелочек от одного отрезка к другому пересчитать несчётное множество иррациональных точек на отрезке - что невозможно, согласно диагональному аргументу Кантора.
Вот и всё, расходимся ?
Вы просто слишком умные ? Судя по описанию, вы звоните в колл-центр уже проанализировав проблему и найдя вариант решения - и вам нужно лишь запустить в работу этот вариант.
Поверьте, подавляющее большинство людей, которые звонят в колл-центры, порой даже не в состоянии сформулировать проблему. А когда формулируют - оказывается, что это проблема из разряда "убедитесь, что компьютер включен".
Ну например. Пенсионерка звонит своему внуку и не дозванивается, слышит странное пиликанье в трубке. Она тут же начинает звонить в поддержку - и если ей ответит оператор, то ему придется выслушивать невнятную историю о том, как бабуля ему каждый день звонит - а теперь дозвониться не может, а возможно с ним что-то случилось, а вот при Сталине телефоны нормально работали и не то что сейчас, а позовите мне самого главного начальника а не этого молодого мальчика...и т.п.
А у неё просто деньги закончились на телефоне - вот и всё ? и зачем ей оператор? Робот сразу ей сам это скажет. И основной поток звонков именно так и отсекается. И именно поэтому роботы и задают такие тупые вопросы при попытке переключиться на кожаного.
А у всяких экстренных контор - аварийные страховые, потеря карты в банке и т.п. - всегда есть отдельный прямой номер для разговора с кожаным мешком в экстренной ситуации.
А что это за загадочная алюминиевая призма с дыркой? ?
Ну вы, в целом, просто переназвали классические GTDшные статусы: PLAN/DO/FOLLOWUP/POSTPONE/DONE. Никто ещё не придумал никакой замены им, все задачи в мире устроены одинаково.
У всех людей мозг устроен по-разному - кто-то может сотню заметок свалить в кучу и помнить каждую - а кто-то не уснет, пока не разложит заметки по тегам, папкам, приоритетам и цветам.
Так что не надо ругать Лумана и Арненса, или называть извращенцами любителей Цеттеля - они не больше вас извращенцы, просто им так удобнее. Главное чтобы задача решалась.
Ancestral-сэмплеры не странные. Они просто добавляют в генерацию немного шума на каждом шаге. Это позволяет чуть ускорить генерацию, но по определению не позволяет получить стабильно воспроизводимый результат с одними и теми же входными параметрами.
В статье про лучшие практики визуализации всего пара картинок с абсолютно скучными стандартными графиками??
Или в суровой России даже визуализация должна быть суровой и текстовой? ?
Судя по фразе "глубина - глубина, я твой", автор ещё помнит, что такое поинтовки и BBS ??
Забавно то, что полученные якобы с помощью ТРИЗ решения проблем всё равно прямолинейные и самоочевидные. Типа такого:
И так далее. Это кстати традиционная боль российских "брейнштормов" - когда собирается толпа умных людей для креативного решения вопроса "Как нам повысить продажи", сидит пять часов не вставая, пишет на карточках странные рецепты из Бьюзена, Микалко и Альтшуллера - и по итогу, с гордым видом, выдает решения, в духе "надо делать больше рекламы" и "надо использовать телеграм, а не смски".
Так и тут - программисты натянули сову своих галлюцинаций относительно пользовательских сценариев на металлопрокатный глобус альтшуллера и получили рецепт в духе "надо показывать рекламу побольше и более короткими отрезками".
А меж тем вам надо было бы всего лишь, например, взять РЕАЛЬНЫХ детей и в каких-то реалистичных условиях смоделировать с ними то, как они будут спрашивать домашку у друга или у учителя. И в каком формате они будут ожидать ответ - ибо очевидно, что дробление домашки на мелкие кусочки и выдавание их порциями забесит ребенка на третьем шаге - и он психанет, скажет: "Алиса, ты какая-то слишком тупая, не можешь мне нормально сказать, чо нам задали!" и не вернётся к ней с этим вопросом больше никогда.
Короче, сценарии надо строить от реального CJM, а не от кабинетных брейнштормов. И вот уже в РЕАЛЬНЫХ сценариях будут настоящие противоречия, на решение которых и заточен ТРИЗ (а не на вымышленные вами самими противоречия). Типа - ребенку надо детально рассказать про домашку, но слушать спич длиннее восьми секунд он физически не может. И вот для этого надо будет придумывать уже НЕОБЫЧНЫЕ методы с помощью брейнштормов и фреймворков для них.
А для подобных очевидных решений в духе "разбить на части" и "сделать заранее" - это вы можете свой YaGPT попросить, он как раз такие ответы и выдает.
Краткий пересказ статьи: выгружаете список задач, считаете сколько сделано/не сделано/зависло/и т.п., строите из этого столбики в Экселе и столбики красите в запрещённые радужные цвета. А дальше вам почему-то станет легче управлять командой - но непонятно почему.
Всё.
Ах, да, надо еще назвать это квантово-волновой диаграммой. Ну потому что у нас квантовые задачи - то ли сделаны, то ли нет - не поймёшь. Логично же. Поэтому ревью задач мы будем называть "квантовые вычисления" - ну типа мы же там вычисляем, какие задачи делать.
"Где папирус получали - туда и идите"
???
Вот действительно странно: статья типа для начинающих и без математики - но ни эмбеддинг, ни даже токен не объясняются как понятия... А дальше по тексту всё равно начинается вот такое:
Это же прям классика из "продвинутых" учебников, где тебе говорят: "Щас мы вам объясним понятие предела на пальцах!!! Вот смотрите - существует такой эпсилон, который больше нуля, да ещё и такой, что при каждом сигма (тоже большем нуля), равном эпсилон-итому, каждый сигма минус эпсилон по модулю меньше дельта! Вот так всё просто! Итак, продолжаем..."?♂️
Очень хорошо! Ёмко и по делу! Ещё бы хотелось почитать, как на практике бороться с этими искажениями. Например, для предотвращения амплификации, ставить ограничение по времени на обдумывание задачи - чтобы люди не залипали и начинали работу с какими-то промежуточными данными на входе.
Два раза прочитал и так и не понял, в чем прикол. Они просто перенесли закон Дарвина на всё вокруг. Типа: надёжно статичное остаётся; гибкое и динамичное - меняется; а если есть опция чот выкинуть радикально новое - ну, так оно и выкинется. И дальше по этой же цепочке отомрет или разовьётся.
Но у этих изменений нет цели, и даже какой-то прогнозируемости или расчетности - как у закона сохранения энергии, который, в этом смысле, именно што закон. То есть мы не можем посчитать, в какую сторону изменится кристалл или там звезда - не учитывая мириады мелких и непостижимых параметров окружающей действительности. А учесть мы их не сможем никогда.
В итоге, весь этот закон сводится к центральной предельной теореме из второкурсного тервера: если объединить вместе несколько абсолютно независимых событий с любыми распределениями, то получится гаусс. То есть если рандомно сыпать песочек, то где-то обязательно получится кучка. Если рандомно смешивать химические элементы - то получится молекула. Это мы знаем точно. Но мы никогда не сможем посчитать - где, когда и какая.
Такие проекты надо начинать с CJM, с пути пользователя и с точками на этом пути. И очень быстро станет ясно, что этих точек не так много - ровно столько, сколько есть врачей общей практики в поликлинике. И то, по каким сценариям работают эти врачи. А врачей не так то и много и они легко разделяются одним простым вопросом: "<Болит горло - к лору, болит нога - к хирургу, болит голова - к неврологу". И нет смысла пытаться определить, фарингит у него или ларингит - всё равно врач будет осматривать заново на месте и писать свой диагноз, а не ориентироваться на то, что там человек накликал в чат-боте. Детали диагноза человек всё равно сам не опишет - ну болит у него спина, тут без специалиста не понять - мышечный это спазм, нервный или ушиб какой. Тут всё равно терапевт нужен. А прийти к хирургу с нервной болью, чтобы он молча перенаправил тебя к неврологу - это уже потеря ожидаемой экономии на осмотре. То есть вся инновационная идея ИИ разобьётся о то, как законодательно регламентирована медицинская деятельность и как работают врачи в реальности.
Примерно, но не так радикально :)
Грань - это рамки бизнес-модели, в которых существует продукт. А бизнес-модель - это не только разработка. Это, в первую очередь, стабильность и предсказуемость результатов при понятном формате взаимодействия и в понятном формате экономики.
В этом смысле, хаотичное допиливание и заваливание итшников рандомными задачами - вполне себе допустимая модель, подавляющее большинство бизнесов прекрасно в ней работает десятки лет. Она приятная для топов с их ЧСВ, она понятная для коммерсов и их коротким горизонтом планирования, она приемлема для акционеров с их совковым видением развития бизнеса в духе "бери больше кидай дальше, от забора и до обеда". Аргументы итшников в этом раскладе просто не будут услышаны, ИТ в данной ситуации - не драйвер бизнеса, а обслуживающее подразделение.
Переход к продукту происходит тогда, когда бизнес осознает, что продукт - это не просто спринты и релизы, а это стабильность развития функционала, гарантия его работоспособности и прогнозируемые затраты на получение понятного результата. Но запрос на такую стабилизацию экономики и прогнозируемость результата должен прийти от тех самых истеричных маркетологов - у которых должна, для этого, появиться стратегия и они должны научиться по ней работать, а не просто класть её в стол. Где-то тут должно появится понимание, что ИТ - это не просто мальчики на побегушках, а бизнес-критичный ресурс, от слаженной работы которого зависит получение коммерческого результата. А значит - итшников нельзя кошмарить лишний раз, нельзя заваливать задачами и отвлекать от работы, нельзя экономить на их штате и т.п. Тогда и начинается серьезный разговор и переход к продуктовым форматам.
Понятно, что и в этих форматах бывает бардак - продукты тоже, порой, допиливаются на бегу и скрам-команды иногда тушат пожары и работают в две смены. Но в данной ситуации это будет скорее исключение, чем правило - а значит не приведет к выгоранию и развалу команды, остановке разработки и, как следствие, остановки в развитии бизнеса.
Спасибо, очень рад, что приношу пользу людям ?
У меня и на тему данной статьи есть прям кейсик описанный (ну как описанный - в телеге описанный для чатика ?), который отлично иллюстрирует все управленческие взаимодействия, которые в данном вопросе возникают. С вашей подачи я даже подумал, что это можно и в статью положить! Займусь, пожалуй, в ближайший день защитника отечества ?
Сорри, я чота нажимаю и оно исчезает, поэтому пишу три камента ?
Это всё строго загоняется в таск-трекер, все загрузки считаются, под коммуникацию с коммерсами выстраивается управленческая методология, ответственность за которую перекладывается на ГД, а не на ИТ. Ну т.е. если ИТ завернуло задачу от маркетологички - то это значит, что маркетологичка не бежит в ГД и не обкладывает ху@ми итшников - а идёт на проектный комитет и сама защищает приоритетность своей задачи в обществе таких же крикливых коммерсов, как она - а на ИТ выносится только финальный список договоренностей между коммерсами. К слову сказать, этот подход довольно быстро сбивает спесь с бизнес-заказчиков - т.к. орать на беззащитного итшника это не то же самое, что орать на коммерческого директора ?
В общем, этой длинной телегой я попытался ответить на ваш вопрос - а где грань?
Грань можно понять, когда разделите разные по формату задачи разработки, поддержки и развития и наложите их на текущий управленческий статус-кво - для понимания того, что из этого реально нужно бизнесу. Звучит сложновато, но в реальности - довольно просто проектируется, зато отвечает на кучу вопросов сразу
То есть вся эта история с разными типами продуктовых команд и спринтов, это в первую очередь история про разрыв в управленческих компетенций между коммерсами и ИТ. И исправлять начинать надо именно оттуда.
Приведу пример - вот буквально три месяца назад ко мне обратилась ИТ-команда из сложного большого ритейла ровно с таким же вопросом: как разнести техпод и разработку и как сделать так, чтобы генеральный не считал нас мудаками?
Про это можно отдельную статью писать, конечно, там много всего фундаментального. Но если вкратце - я им предложил разнести их работу на три разных сценария с разными SLA:
Техпод - это быстрые короткие задачи от которых зависит выживание бизнеса. Сиюминутное реагирование, высший приоритет - но список задач ограничен
Хотелки - это реализация хотелок бизнеса, но через призму оценки трудоемкости, жёстких приоритетов и четких SLA: сказали через месяц - значит получите через месяц и не орите ?
R&D - это четкий процесс долгосрочного развития систем, а также реализации хотелок, которые на первый взгляд были "изи", а как копнули - то стали "так блэт". Тут уже свои, очень длинные, сроки и другой формат взаимодействия с заказчиком![]()
![]()
А это зависит, опять же, от бизнес-задачи, страт.планирования и управленческой силы ИТ. Потому что поддержка и разработка различаются, в первую очередь, с точки зрения бизнес-процессов и их параметров: преимуществ, производительности, прямых затрат и затрат косвенных (например, усилий, требующихся чтобы убедить два десятка пузатых директоров в том, что ИТ - это не помойка для их гениальных идей, а четкий механизм, работающий по своим правилам)
Вот смотрите. Спринт - он для чего нужен? Если просто - то для того, чтобы продукт выходил вовремя и без косяков, а также - чтобы разрабы не зашивались и не рвали волосы, метаясь между потоком задач от орущих маркетологов. А далее вопрос - а самим маркетологам это нужно? Как правило - им плевать на план и регулярность, им надо ad hoc - потому что так работает вся компания.
И даже если на словах ИТ-директор может договориться с генералом о том, что "спринт - это важно, стратегия - это важно, давайте придерживаться и т.п." - то закончится это тем, что генерал всё равно потом придет и скажет: "Ладно, пацаны, ну чо вы со своими спринтами - ну сделайте вы уже фичи этим маркетологичкам, у них же клиенты там, бизнес, продажи..."
Всё, значит стратегия не работает на самом высоком уровне. И значит, что для всей компании сиюминутное реагирование и тушение пожаров приоритетнее, чем планомерное движение к цели. Ок, это ни плохо, ни хорошо - это просто статус-кво. Просто этот статус-кво не бьётся с желанием ИТ делать всё системно. И аргументы типа: "У меня команда выгорает от неравномерной загрузки задачами, постоянного негатива от коммерсов и постоянно вчерашних дедлайнов!!" - эти аргументы не волнуют генерального. Ему плевать, что там с командой - ему важно, чтобы выдерживался привычный ему стиль работы: приказ отдал, побежали выполнять без вопросов. Что ж, такова данность и дальше надо думать, как в рамках нее существовать - есть ли у вас влияние, чтобы убедить генерального? Есть ли у вас полномочия, чтобы отказывать коммерсам? Есть ли у компании ресурсы, чтобы дать вам правильного объема команду? Есть ли вообще хоть у кого-то понимание, куда он идёт - и как это положить на ваш план? ?