Хабр Курсы для менеджеров
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток Менеджмент доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 27
>Выбор идёт между усталостью на согласованиях и переделками после запуска
Нет такого выбора. Это лишь перекладываение ответственности за принятие решений на заказчика до того, как работа будет начата. Больше ничего. Заказчику реально это не надо, так как он редко сам ещё понимает, что хочет. Всем надо поиграться с каким-то прототипом и осознать, как лучше делать и делать ли после прототипа что либо вообще. Это естественный жизненный цикл нормальной разработки (при условиях, что разрабатывается новая для заказчика тема и есть возможность дорабатывать потом, либо всё выкинуть).
И да, это всё полностью противоречит следующему вопросу заказчика, а сколько это всё будет стоить, при полном нежелании включать голову в продумывание требований. И решений этому не особо, кроме как оценивание и выполнение мелких этапов, где все осознанно идут на риск. Одни не знают, что получат, другие не знают - попали ли в оценку. Либо полный ТМ где риск берёт на себя заказчик и опытные заказчики вполне осознанно на это идут.
Нормальная работа и ведется этапами. А чтобы заказчик понял что он хочет и делаются сначала макеты, потом прототипы, потом собирается обратная связь и проводятся доработки. Я в целом об этом и пишу в статье. Тут и возникает та самая усталость.
А иначе мы просто делаем «как в тз» быстро и потом получаем «мины» уже на проде в готовой системе.
Если делать так, то проще вообще купить подписку на нейросети и писать себе сервисы самостоятельно. Многие так и делают.
Все уже друг от друга устали. И от расходов и от "качества" и от суровой реальности, где куча граблей и проблем, которые вдруг чудесным образом не исчезают с новым поделием. Поэтому SaaS и прочие силвер буллеты взлетали, теперь падают, ибо не буллеты по факту. Скоро и от агентов устанут, так как тоже не буллет.
Я с вами согласен! В первых версиях статьи у меня был блок посвященный усталости. Я его оставил для отдельного материала.
Как-то многовато у вас спорных утверждений на один комментарий. SaaS давно взлетел и оснований его хоронить нет. Хоронить агентов, которых пока никто ничем не заместил - это вообще чудовищно преждевременно. Да и любое решение пришедшее им на смену все равно будет базироваться на ИИ, это уже аксиома.
Если заказчик сам не понимает, что он хочет - вы никогда не сдадите такую систему.
Заказчик должен понимать, что он хочет. Требования могут меняться и дорабатываться при разработке системы.: что-то не предусмотрели, что-то поменялось, для чего-то нашли лучшее решение... Но "то что заказчик хочет" не меняется. Меняться может "то как он это хочет получить".
В противном случае, получится система которая будет соответствовать формальным требования ТЗ, но будет совершенно не рабочая и бесполезная для заказчика.
В том числе об этом и статья и ответ на прошлый коммент. Наша задача помочь заказчику понять что он хочет. И улучшить то, что он уже придумал.
Я почти всегда пытался добиться от клиента, а точнее от тех кто с ним связываются, узнать не "чего клиент хочет [чтобы мы сделали]", а "чего клиент хочет добиться, какая цель".
Чаще всего бывало так что то что хочет либо было мимо цели, либо до цели добирались окольными путями. Это в основном либо от незнания специфики софта, либо нюансов нашего направления, с которыми мы уже часто сталкивались и могли подсказать и решить проблему/задачу гораздо эффективнее, зная какие решения добьются цели скорее.
Это вы описываете идеального исполнителя. А такие встречаются редко.
Если заказчик сам не разбирается в системе - подход правильный. Он не знает продукт и объясняет на своих процессах, что ему нужно. Исполнитель вникает в процессы заказчика и предлагает грамотное решение.
Однако, мне встречалось другое: исполнитель приносит решение, которое не ложится на процессы заказчика. Всё по методологии вендора, красиво расписано, хорошо задокументировано (и даже идеально реализовано), но на практике это не просто неудобно, а разрушает рабочие процессы.
Либо у исполнителя не было специалиста, который способен это увидеть, либо не было желания вникать в процессы заказчика.
Всё зависит от того, есть ли у сторон нужные компетенции и насколько сильны специалисты.
Фиксед прайс - не единственная модель разработки софта. Многие опытные заказчики вполне осознанно выбирают ТМ, так как понимают, что им нужен результат, а не абстрактная цифра с гарантированными тёрками.
Это не опытный заказчик, а заказчик хорошенько обработанный меркетолагами. Ни один адекватный заказчик не будет вливать деньги не имея представления о том когда это кончится и что он получит в результате.
Внедрение программного продукта это вполне себе фиксированный процесс с началом и концом.
Потом, уже работающий продукт, можно дорабатывать. Внедрить новые модули, менять уже внедренные и т.д.
Но даже в этом случае, это будут отдельные проекты с началом и концом.
Ну и да, не стоит путать внедрение с сопровождением и поддержкой. Это очень разные процессы с разными задачами и методами.
В моём пузыре большинство заказчиков ТМ, так как целенаправленно их выбираем, вдоволь походив по граблям с фиксом. И как правило фикс требуют именно малоопытные заказчики. Те, кто уже годами разрабатывает, прекрасно знает, что жизнь продукта не заканчивается деплоем первой версии на сервер и именно после релиза и начинаются пляски. Поэтому ТМщики берут себе по сути на аутстафф как часть своей команды и владеют своим софтом.
То что описано у вас не внедрение. Это что угодно: поддержка, сопровождение или доработка — но не внедрение.
Внедрение — это реализация конкретных процессов на конкретной платформе в заданных временных рамках. Его цель — перевести эти процессы на новую платформу. Внедрение почти всегда разбито на этапы, и первый релиз никогда не бывает финальным. Но у него всегда есть перечень целей и задач, которые должны быть решены, и сроки, в которые они должны быть решены.
Когда внедрение завершено, предприятие получает систему, в которой может полноценно вести свои процессы. Не обязательно все сразу и не обязательно идеально — но поставленные цели и задачи внедрением решены.
Дальше начинается сопровождение продукта: силами заказчика или сторонней организации. На уже работающей системе в рамках сопровождения можно менять процессы, оптимизировать их, добавлять новый функционал. Но это именно сопровождение, и у него другая логика управления: не фиксированный объём работ до результата, а регламент, SLA, приоритеты и поток задач.
И даже в сопровождении заказчик и исполнитель согласовывают стоимость и сроки работ. Просто согласовывают их иначе, чем при внедрении.
Ещё раз - мой поинт в том, что бывает иначе. Когда сама компания ведёт разработку продукта хотя бы в виде работающего прямо в компании продукта/PMа/CTO/кого угодно. Часто есть ещё локальный штат. И команда (команды) аутстафферов. И всё это на ТМ, ГОДАМИ. Называть всё это неопытным заказчиком, обработанным маркетологами - ну такое себе. Это бизнес модель, отдельная от фикса.
Вы уж определитесь о чем рассуждаете. То "выбираете заказчиков", то "сама компания ведет разработку", то это "отдельная бизнес модель".
Я вам про Фому, а вы мне про Ерему...
В ТМ тоже есть сроки. В ТМ тоже есть критерии приемки работ. Просто сроки короче, задачи локальней а бюджет закладывается. Даже бюджет там тоже есть. Просто считается и расходуется иначе.
И в плане управления проектом (развития программного продукта) разницы между ТМ и Фиксом не будет ровно никакой. ТМ и Фикс - это просто условия оплаты, а не методология.
Для внедрения программного продукта, а мы изначально обсуждали именно его, ТМ плохой выбор. Да, в случае когда компания не имеет зрелых бизнес процессов и в принципе не очень понимает что ей надо это будет практически единственный вариант. Но по сути это и есть незрелый заказчик.
Есть еще вариант когда компании просто не хватает собственных исполнителей для реализации всего объема работ в срок. В этом случае, внедрением занимается сам заказчик, а исполнитель просто дополнительные руки. То есть, по сути, тот же самый проект с фиксированными сроками, бюджетом, объемом работ, но с привлечением дополнительных сил. Но это уже не TM, а outstaffing в рамках проекта. Похожее, но все же разное.
А вот для поддержки и дальнейшего развития, ТМ вполне себе подходит. Задачи появляются постепенно и закрываются по необходимости. Но тут и объем работ иной, и стоимость, и срочность не сопоставима с внедрением. И цена ошибки ниже. О чем я собственно уже писал.
+100 - много раз наблюдал что такие вопрошающие просто боятся брать ответственность за решения и им все надо согласовать 10 раз
Я вспоминаю этот случай каждый раз, когда слышу, что систему теперь можно просто сгенерировать. Технически там всё было в порядке. Система была. Просто не та.
Как я вас понимаю. Когда слышу, что сейчас всё можно "навайбкодить" - сразу понимаю, что такие комментарии осталяют люди, которые сами еще не пробовали "навайбкодить" реальный продукт. Я свой продукт делаю уже несколько месяцев, и постоянно возникают всё новые и новые доработки. ИИ сейчас очень силен, но всё же ему еще далеко до человеческого понимания природы вещей, на мой взгляд. Именно человеческого.
Все так. Я тоже свои личные (даже коммерческие) сервисы преимущественно пишу "вайбкодом". И новая жизнь у проекта начинается когда его начинают использовать настоящие пользователи. Тут и эдж-кейсы и гонки в бд и прочие прелести.
В b2b системах это не так чувствительно, там обычно не работают сотни тысяч людей, но продуктовые ошибки возникают и через год и через 5 лет. С накоплением данных появляются новые случаи. Это если не брать в расчет, что бизнес развивается и у него меняются процессы и требования.
Последний пункт на практике самый показательный. Подрядчик, который принимает ваше задание без единого вопроса скорее всего в нём не разобрался.
В этом случае я начинаю сам задавать вопросы и сам же на них отвечать, потому что я больше всего заинтересован в том, чтобы заказчик понимал, что происходит и как работает.
Если заказчик не может эксплуатировать созданную систему, он будет пытаться эксплуатировать разработчика. А кому это надо? Никому это не надо.
Даже на собеседованиях и при обсуждении ТЗ, регулярно приходится: "позвольте подсветить еще несколько моментов, которые не прозвучали, но также важны, начнем с лицензирования компонентов участвующих в системе... все модели используемые в системе являются национальными...система удовлетворяет требованиям класса защищенности 1Г в соответствии с РД ГТК РФ... и тд".
Причём тут "спорить", "вопросы"?
Собирается ли заказчик автоматизировать и консервировать существующие бизнес процессы или собирается их менять?
Вещи совершенно разные, а вы их смешали
А что вас смущает? К примеру он хочет законсервировать процессы. Как довести систему максимально быстро и дешево до гарантированно подходящего заказчику результата не проводя такие работы? В своей статье размышляю что по-моему опыту никак. Только чисто на рандоме если.
Суть «спора» не чтобы поменять процессы, а чтобы помочь их правильно выстроить.
>За этот год процессы перетряхнуло у всех.
Плюсую.
ИИ - интеллект искуственный. Не настоящий.
Сильный сейчас не ИИ, а скрещивание тонны бекенд булевой логики с ИИ оркестратором под флагом - агент.
Вайбкодят все агентами. Сделать за день можно что угодно - да, размером с игрушку. Как танк из картона, у него вроде и пушка на месте и цвет зеленый и кабина есть - только посадить туда можно одного человечка - и тот покемон.
Переделать то что навайбкожено - проще заново навайбкодить. Это и назвали макетами.
Создать боевой танк без настоящего интеллекта невозможно. В ИИ агентов на все 50 ультра подписок можно спихнуть изготовление 100 000 деталей игрушечного размера. И потом ещё в агентов на агентов сборку в продукт. И всё равно нужен постоянный надзор за происходящим.
И времени в итоге уходит не чуть не меньше на продукт, чем раньше. Просто оно тратиться на вообще другие вещи. У вас армия бестолковых миньонов, у которых ограничено контекстное окно и у них всё каждый раз как в первый раз. И они ещё на пределе всегда и генерируют код на все ваши бабки с такой же суммарной скоростью, с какой вы его и печатали всегда. Поставил задачу - прошло пол часа, произошло по 4-5 строк кода изменений в 50 файлах. Запустили ии ревьювера, ии тестировщика - они вроде всё проокали, потом через 2 часа всё померло, потому что они окали баги и думали что всё прекрасно. Хьюман ин зе лупа - сказали надо - ревью на нас и точка. Теперь снова 30 минут шкодит армия желтых психов в подгузниках - и теперь мы за ними проверяем всё тщательно. 2 часа спустя кейс закрыт, колонка прокинута с фронта на бек до субд. Миграция написана - счастье радость авации.... Сам бы за 5 минут сделал, а тут гордость испытываешь как за дитя, которое сделало первый шаг. И думаешь ну да код писать руками уже лень и не модно.
Но вмять за ногу - у кого и когда вообще были проблемы с написанием кода? У джунов? Которые только первую книгу про код прочитали? Все эти болячки после года энтерпрайза заканчивались у всех и сразу и за быстро.
И вот процессы перевенулись) С написания кода в болтовню с заказчиком. Куда и с чего? Примерно никогда не было важно какой там код у тебя красивый или правильный. Хотя были там всякие инфоцигане и курсопродажники, утверждающее иное. Но они просто бабло стригли на маглах, нельзя их винить за это. Реальным разрабам, которые собирали эти порталы с курсами - надо было платить зп с чего то. Машина капитализма - вся херня, так бывает.
Важно всегда было что код делает, зачем и за какой бюджет рантайма по железу. За чей счет банкет по бабкам на проекте и какую пользу он принесет бизнесу. И где то там в конце списка код.
И про заказчиков - матрицы требований и всякое "занудное" существовало и до ии. Как компьютерное зрение, распознование речи и эмбеддинги с векторными базами.
И как бы странно ни было - обычно есть такой человек у бизнеса - методолог. Который понимает почему у бизнеса такие процессы сейчас, как бизнес работает, зачем в текущем бизнесе такие системы, и что в итоге они хотят изменить. Если конечно гендир выполняет там такую роль и бизнес не супер крупный - ну ему никуда не убежать от вопросов. И Ваша задача всегда стать по сути учеником методолога - чтобы понять его боли. Придется разобраться в предметной области, а не только в том как в ии пихать задачи. И понять мир где варится закзачик. Тогда вы и сделаете систему какую надо. Потому что не Вам расскажут что надо. А вы сами поймёте что надо Вооооот что. Это как дип рисёч, но только не в то как распознать картинку с точностью до 100% - а в то как понять боль заказчика по двум его предложениям - я бизнес такой то, численность такая то, в процессах таких то нам не хватает вот этого.
И Вы пошли через ии агентов копать и учиться что за бизнес, какие там процессы, что с чем связано. Как там работают люди, в чем. Что едят на завтрак и почему это влияет на пропускную способность цеха. Раскопали всё что ток могли. Поняли и тут бац - вернулись к заказчику как его заместитель и такие - ну вот так делаем.
Вот чего все хотят сейчас. Чтобы всё само делалось)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Код всё чаще пишет нейросеть. Чем тогда занимаемся мы