Хабр Курсы для менеджеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Менеджмент доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 51
Так сколько всё-таки стоит эта система?
Мой ответ: от 300 часов, если принять все мои допущения, и до 5 000+, если не принимать ни одного. Диапазон — не признак плохой оценки, а признак того, что оценивают не систему, а сочетание системы с условиями её создания.
Из практики, фактические трудозатраты плюс-минус совпадают с оценкой, хотя сам проект всегда разбухает за счет новых требований, и только в половине случаев заказчик это справедливо и безоговорочно принимает.
Лет 5 назад ещё до этих ваших LLM видел прайс компании (и открытую и закрытую часть, мне его показал продажник). Там типовые повторяющиеся работы довольно дёшевы. А потом начинаются справедливые накрутки: количество интеграций, наличие качественной документации, был ли уже просмотрен заказчиком и согласован прототип, наличие кастомных решений где в лучшем случае не набита рука, а в худшем случае нет компетенций...
Я работал с обеих сторон — и подрядчика, и заказчика, и сейчас я вижу удивительную вещь: как будто утеряно огромное количество наработок по культуре разработки, по точности оценки, взаимодействию с заказчиком — всё это заметно просело.
Единственное что радикально изменилось — количество грамматических ошибок. Раньше было интересно вычитывать текст на сайте и в приложениях, и всегда можно было что-то найти эдакое, а сейчас скукотища :-)
как будто утеряно огромное количество наработок по культуре разработки, по точности оценки, взаимодействию с заказчиком — всё это заметно просело
Да, главное забыл упомянуть: UX — пользовательский опыт. Всё убил material design, и теперь не важен комфорт пользователя, а важно соблюдение некоего феншуя, когда ты тычешь вроде в поле ввода, но промахиваешься, потому что кроме нижней границы у него нет никаких визуальных ориентиров.
Всё убил material design
Ну не берите его.
Material Design - нарезать интерфейс из бумаги
Apple Human Interface Guidelines - воздушный дизайн, много свободного места, мало границ и областей
Microsoft Fluent Design System - похож, офисный
Carbon Design System - энтерпрайз, скучно и удобно
Ага, глядя на все эти штуки понимаешь слёзы умиления у прогеров из поколения X, когда они видят стилизацию под ламповый интерфейс для винды, на VB6 с аккуратными попиксельно выведенными элементами управления.
Bootstrap от бывшего Twitter всё ещё в топе 2, если веб.
Эдди Османи (Google Chrome DX) в декабре 2024 назвал это «проблемой 70%»: первые 70% решения появляются на удивление быстро, а оставшиеся 30% — крайние случаи, безопасность, интеграция с реальностью — остаются такими же трудными, как раньше
Миллениалы открыли закон Парето.
Ну, не миллениалы, а Bell Labs, 1985 (правило 90/90). Цитирую это тут не как открытие, а как единственную часть кривой, которая за последние два года не подешевела
Правильно, 90% (или 70% по Парето) не подешевела.
Хотя, если вы хотите жить с деталями, привинченными к не предназначенным для этого местам, то эту часть можно не учитывать
Ага, «привинчено» видно по оценке: как только требование не ложится на готовые примитивы, цена возвращается к отраслевой. Статья как раз про это — 0,73 ч/FP действуют только внутри домена, который инструмент моделирует.
Вот сегодня разбираю результат "вайбкодинга" гастарбайтеров какой-то южной страны.
Сарайчик из металла, собирается как ИКЕА, все должно подходить друг к другу, только надо правильно повернуть. Эти быстро сделали дырки в других местах и прикрутили. Заметно стало в конце, когда детали не сошлись. Пришлось полностью разобрать.
Они видимо жене свой тоже дырки дополнительные делают если куда надо не попали.
Кстати, аналогия LLM с IKEA зашла. Надо запомнить. Готовый набор деталей подогнанный друг к другу дёшево, любой кастом дорого
Первый проект, созданный с нуля ИИ, я переделал полностью, от структуры данных до рабочих мест. Теперь делаю постранично и внутри страниц — поэлементно. Прикрутил память кстати, сейчас наблюдаю.
Они видимо жене свой тоже дырки дополнительные делают если куда надо не попали.
А как, по-Вашему, анал появился?
(или 70% по Парето)
Кхм, вообще-то по Парето 80%
Ведь не в этом суть, вы же понимаете, не в числах, а в том, что, как в народной мудрости: чем ближе, тем трудней.
Вплоть до того, что у физматовцев называется парадоксом черепахи — путь к цели бесконечен, потому что бесконечно количество половин остатка пути. Такое и раньше наблюдалось в любой сфере (ремонт нельзя закончить, а только прекратить), а теперь, с наплывом непрофессионалов с профессиональными инструментами, вообще будет весело.
Именно эта мысль возникла при прочтении
" с ИИ сейчас всё делается за вечер" - вот пусть сам и делает.
Первоначальная реакция у меня примерно такая и была. Человек честно уходит и делает сам, один из таких людей потратил 4 месяца и примерно 800 часов, так и не сделал (строительная тема — система мотивации). Я отправил ему эту статью.
Сейчас я так больше не говорю — это грубо и неблагодарно, просто расстраивает людей. Они ещё вернутся — деваться-то им некуда. Как говорится, скупой платит дважды.
Архитектор-разработчик временно обесценен, и это несправедливо, но всё вернется в норму рано или поздно. Кодерам — да, каюк.
Архитектор-разработчик временно обесценен
У нас нет, слава Богу
Видимо, руководители олдскульные
Архитектор-разработчик временно обесценен
Это с чего вдруг? Наоборот, кодер, считающийся почему-то разработчиком, «вдруг» стал не нужен, ии кодит лучше и быстрее. Тут-то и вскрылось, что большинство — кодеры, а не разработчики.
А ваш заказчик почему-то думает, что разработка — это кодинг. Я так и не понял по вашей статье, что в итоге? Если заказчик считает, что 300 часов это много, ну тогда пусть сам и кодит с помощью ии. Или вам удалось убедить, что 300 это норм или даже мало?
Это с чего вдруг? Наоборот, кодер, считающийся почему-то разработчиком, «вдруг» стал не нужен, ии кодит лучше и быстрее. Тут-то и вскрылось, что большинство — кодеры, а не разработчики.
А ваш заказчик почему-то думает, что разработка — это кодинг.
Заказчика нужно обучить — кто есть кто, сейчас он пребывает в эйфории: ИИ может всё!
Он самообразуется, мы его не переубедим аргументами в моменте, надо подождать, но не грех подкинуть ему и полезную, подкрепленную фактами информацию.
Я так и не понял по вашей статье, что в итоге? Если заказчик считает, что 300 часов это много, ну тогда пусть сам и кодит с помощью ии. Или вам удалось убедить, что 300 это норм или даже мало?
Пока мне не ясен вывод конкретно этого заказчика, ответа на предложение нет, за статью он меня поблагодарил лайком, не более :-)
Почему бы просто не оценивать в story points и не считать velocity?
Потому что velocity нельзя предъявить заказчику до начала работ и тем более сравнить с индустрией. Для внутреннего планирования итерациями story points лучше, а для разговора «сколько это будет стоить» нужна внешняя, по отношению к команде, шкала.
Потому что story points для типовых задач подешевели, а ещё потому что демо теперь дешёвый. Но никто не заметил, что не стали дешевле для нетиповых задач, для интеграции и ещё много чего.
И в story points трудно оценить, надо иметь большую статистику
Или если нет большой статистики, то story points превращаются в субъективные оценки низкой точности и высокой манипулятивности
Даже если есть статистика, SP имеют разный вес у разных команд, то есть разный курс обмена на часы/деньги, что очень ненадежно при оценке проекта. Внутри команды это не несет рисков и как раз поэтому часто используется для манипуляций, как, например, и lead time, на которые все просто закрывают глаза ради хорошей картины. Перед заказчиком такое не пройдет.
задумчиво А вы за оценку ТЗ деньги берете? Я бы лично только за чтение всего этого цирка и дачу фидбека (с оценками) тысяч бы 40 взял...
А вообще немного обидно, что идет отказ от типовых платформ и начинается "сделайте нам по ТЗ". Потому что архитектор может понимать, что, например, если не делать кастомную систему ролей (процедуру регистрации, CRUD и пр.), а взять некое стандартное решение в платформе, то оценки сильно пойдут вниз, и будет сильно дешевле. Да, не будет, как хочет заказчик - но может, ему это и не нужно-то в общем, а написал он это в ТЗ, потому что "ну просили же сказать, как он хочет". Делать же реализацию "строго по правилам" дорого, конечно.
Функциональные точки - позавчерашний день, зачем они в 2026-м?
Как метрика планирования — возможно. Как единица сравнения — нет: это единственная широко распространённая мера объёма, она не зависит от языка и стека, и по ней есть открытая отраслевая статистика. Мне не нужно, чтобы FP предсказывали срок; мне нужно перевести свою оценку в шкалу, где её можно сравнить с тысячами чужих проектов.
Попросил я как то очень умную ИИ накидать требования на таких вводных: "Хочу вот такую систему и вот так и чтобы тут аж так, а потом вот тут бац-бац и красота! И да, на андроиде хочу и сайт хочу!". Накидала. Пишу ей: "Верни их в ТЗ", вернула. Накидать архитектуры - накидала, на этапы разбить - разбила. Потом прошу вернуть оценку трудозатрат в человко-часах, с ролями и прочее. Вернула. Что то там 3-и месяца в 3 лица. Ну я потом спросил в другой сессии: "Вот требования, вот ТЗ, вот архитектура, вот этапы. Кожаные сделают за столько. А рой ваших за сколько? Чего вашим не хватает во вводных и чего докинуть?". Ответила, что у её роя уже всё есть и они всё сделают за 3 дня, из которых 2 дня мне надо курить их конвейер. День рой будет совещаться и писать софт и на выходе выдадут мне адрес действующего сайта и apk для установки и инструкию что делать. Пояснила, что это будет прототип проверить мои гипотезы, особенно пункт "бац-бац". Я еще ради прикола попросил одного из роя в промпте сделать строгим надзирателем с фразами "шнель! натурлих!" и прочими.
Кроме шуток, я конечно понимаю, что общался с LLM исходя из своего собственного опыта самостоятельной, командной и управленческой работы и держал этапы как разработки так и эксплуатации в голове. Но скорости меня заставили вообще абстрагироваться и взглянуть на всё происходящее с другой стороны. От идеи до прототипа для проверки гипотез всего то несколько часов.
Я уже такое проходил много лет назад с ECO Bold, потом с MDriven и прочими low-code платформами. Когда проверенный прототип отдавался в изготовление, потом ко мне возвращались подрядчики с "мы этот прототип превратим в приложение за 2 месяца, на java перепишем и это будет стоить ....". И прикладывали расчеты как у автора статьи. Однажды были посланы заказчиком со словами, что ему и прототипа хватает и гипотезу свою он уже проверил.
Давайте честно: всё равно вашу будущую систему будет писать LLM, просто контролировать результат будет технически грамотный специалист, а не заказчик которому будет тяжело понять все эти ваши куберы с ингресами.
Давайте честно: всё равно вашу будущую систему будет писать LLM, просто контролировать результат будет технически грамотный специалист, а не заказчик которому будет тяжело понять все эти ваши куберы с ингресами.
Верно.
Сейчас переходный период, и мы ещё не знаем границ, в которых LLM будет способна расширить свою зону ответственности, особенно неконтролируемой ответственности, что массово применяется уже сейчас: чем делать ревью, проще подряд закинуть серию тикетов, тыкая агента носом в косяки, и он там как-то докочумает до нужного результата (не без пасхалок, конечно, но это тоже вполне решаемо его же лапками). Пока это применяется только в узких бюджетах, для розничного/мелкого заказчика, потому что им "дорого". Но скоро вырастет поколение, которое иначе и не умеет.
А вот такой вопрос, чисто из любопытства, даже, может, не к автору, а к аудитории - А если взять всё имеющееся ТЗ, все брифы, все чаты и переписку по проекту, закинуть Клоду в папку и на максимальных настройках попросить дать оценку с учётом исполнения не самой дорогой, а самой подходящей моделью - что будет? Совпадёт? ИИ начнёт задавать правильные вопросы? Или выдаст не имеющий отношения к реальности бред? Кто-то пробовал?
В бенчмарках обычно пишут рекомендации, какая модель для чего лучше. Клод вам даст в этом случае общий совет, типа делайте архитектуру Опусом 4.8, а кодить по ней заставляйте Кодекс. ИМХО, это только лишняя возня, если есть Опус :-)
Я обнаружил, что собирать данные и ставить ТЗ на что-то совсем новое лучше Соннетом или даже Дипсиком, а также писать какие-то простые скрипты быстро. Но не потому что они это делают лучше, а потому что быстрее и с приемлемым качеством.
Кстати, в попытках улучшения ИИ-продуктивности мы придумали память со смыслом: постоянная память для ИИ-агентов, которая живёт в Postgres, который у вас уже есть. «Гирлянда памяти» возвращает не просто похожее, а причинно-связанный граф прошлых решений.
Опус (не Opus!) начинается тут:
Не дали ИИ-агенту соврать — его же памятью
Так а результат-то какой? Даст неонка, которая унутре у ей, оценку, близкую к реальности?
(сорян, промахнулся, надо было в предыдущий тред, админы, если можно - двиньте?)
А нет ли у вас методики для оценки переделок? Когда ничего не меняется внешне, либо меняется незначительно, но результат работы системы другой.
Тут ИИ уже не поможет, надо организационно. Правильно (из опыта) так: в какой-то момент признать основную работу выполненной и перейти на оплату по часам в рамках доработок/поддержки, так проект не втягивается в бесконечную сдачу и экономит всем нервы. Кочки зрения у заказчика и разработчика разные, и не все готовы двигаться, из самой разной мотивации.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«Оценка 300 часов? ИИ мне сделает за вечер!». Считаем тремя методами, и 300 — ниже плинтуса в индустрии