Для заказчика недешево получалось. Но так да, это не про проекты на 100500 мильонов - это про долину смерти, где для заказчика уже дорого (но для него все дорого, что больше 10 тыщ рублей) а для сложности проекта в 3-5 раза меньше, чем хотелось бы. Но статья не про это, а про то, что в сложном проекте, прописать все-все-все требования да так, что бы получилась рабочая система - нереально. Для строительства это научились делать, но это адская стоимость - это примерно как проект 10 этажного многоквартирного дома со всеми коммуникациями (у меня профильная вышка по строительству). Те многократно превышающая доступный бюджет. Ну и как бы и в этом процессе заказчик может решить, что был неправ и надо бы слиться с пейзажем (что в стройке сплошь и радом). И там вот очень очень распространено порционное взаимодействие.
Ну ты че... какой дикпикпик :) Там же написано, что да — без менеджеров и аналитиков и на недорогом проекте, где на них нет денег. Но если че и с менеджерами и с аналитиками будет все тоже плюс-минус самое. Идешь и выявялешь требования и на старте понятно, что будет фейл. Ранее там в комментариях было хорошо указано кем-то, что требования-требованиями, а чел со стороны заказчика, которых хочет их исполнить как требуется и подтверждает это полномочиями и деньгами — вот это задача на стоимость всего проекта. Он даже может и быть, но при этом тебе как подрядчику платить не хочет, или хочет, но как-нить потом в следующей жизни. Че дикпик с этим блин делать будет?
Да, есть чуваки (их много) которые предполагают, что если платформа стоит там условно тыщу рублей в месяц, то и месяц работы по проекту ну не дороже 10 тр., да и вообще как-то само должно. Такие отсеиваютсяяв другую сторону.
Это хорошая история, но думаю, что бы в такой форме это было возможно — это бюджет за 15М должен быть. И цель-то всегда будет хорошо сформулирована, она не мешает потом все делать по другому.
Я сейчас придерживаюсь того мнения, что если есть ресурсы и проект большой — 100% делать внутри. Могут быть отдельные технологии внешние, но именно как вещи в себе, а вот эту всю систему взаимосвязей надо генерить внутри, так как любой аутсорс создает адские издержки на коммуникацию — просто кошмарные. нет ничего такого в SAP, что нельзя собрать внутри за разумные сроки и собрать при этом именно так, как нужно. IT-система — это управленческая задача во всех смыслах, успешны те, кто это понял.
Дело в том, что не всегда на старте понятно, что же там надо сделать и заказчику в том числе. Это не проблема — проблема именно в том, что подряд предполагает (и заказчик часто именно так и хочет), что бы затраты на поиск правильной комбинации были переложены на подрядчика. Те эксперементирует заказчик (меняя требования), а выгребать из этого должен подрядчик. Заказчик при этом может быть вполне нормальный, но вот он исходит из того, что я же не разбираюсь в вопросе — мне нужна поэтому конечная стоимость, иначе это будет проект с бесконечными затратами. Какой здесь вывод можно сгенерить — заказчик должен обладать квалификацией сам, что бы заказывать сложное что-то. А если там чуваки «да мы тут не понимаем, это вы специалист» — от таких сразу бежать надо с третьей космической — вот это всегда фейл.
Не, про другое статья, что если кто-то хочет за деньги — то надо настойчиво требовать деньги :) И про то, что если кому-то, что-то нужно в бесплатном продукте — то надо 3 раза подумать делать ли это, так как это запрос от неплатящей аудитории.
Ключевое наверное - это обновление базы и самого приложения. Нельзя просто обновить контейнеры, нужно изменять бд. На втором месте, что требовалось больше инструкций и нам приходилось на каждую фигню писать инструкцию для докера и не для докера, пользователи их обязательно путали. На третьем, что наш докер образ никому не нравился, так как должно же быть все атомарно, как у mailcow - 10 контейнеров и compose. Это уже требует, что бы пользователь был спецом по докер. И в конце стало понятно, что нафиг докер.
В сложных проектах результат зависит также от заказчика, как и от подрядчика. Поэтому когда мы прописываем в договор результат, зависящий от заказчика — ну все, его больше чем в половине случаев не будет (что и видно во всякой разной статистике). Но вообще в таких небольших бюджетах никому не рекомендую брать сложные проекты на разработку — бизнес из этого не получается. Отчасти потому, что определить за короткий срок первоначального обсуждения проекта, что там на самом деле творится у заказчика — нереально. Там все будут очень внимательны и заинтересованы до момента, когда разрабатываемая система начнет реально наступать им на ноги, и где это — дистанционно понять невозможно. Становится понятно через пару месяцев и дальше происходит попадание в инферно. Для того, что бы терпеть его жар и нужны манагеры, ропы, юристы и бухгалтера, что бы можно было организовать там комиссии по заинтересованости и как-то отгородится. Но если у кого-то всей этой ватаги нет, то либо как описано выше, либо проекты максимум до 100 тр за раз и очень важный навык — выключение телефона и игнор (пользоваться придется часто), либо еще можно согласится, что реальная эффективная ставка будет типа 500-600 р./час с квалификацией с которой можно в Сбере чилить с окладом 400К и смузи. Поэтому не получилось у нас сформировать базу подрядчиков, которые бы на заказ проекты делали — там просто никто не выживает, нужно либо сложность проекта меньше раза в 3, либо бюджет больше раз в 5, а такого нет. А когда сами для себя внутри делают — все ок, работает.
Кстати хорошая тема с желающими - когда не два плюс два проект, то и задачи сложные и по факту почти все рассасываются. Что бы кто-то вот прям улучшал проект - это он должен быть ему лично очень нужен в этом улучшенном виде. И потом очень важно, что бы в итоге в коде концы можно было найти. Поэтому проекты, которые разрабатываются сообществами, во первых очень медленно разрабатываются, тратят оргресурсы с КПД парового двигателя и во вторых, внутри часто представляют из себя божественный хаос.
"Хорошие иллюзии" - забрал к себе
Да все тоже самое, поэтому все попробовали и рассосались. Заказчики дальше как-то там сами в экселе. Новых не берем.
Да, у него может быть множество причин "переключить внимание" не зависящих от качества исполнения заказаной системы
Для заказчика недешево получалось. Но так да, это не про проекты на 100500 мильонов - это про долину смерти, где для заказчика уже дорого (но для него все дорого, что больше 10 тыщ рублей) а для сложности проекта в 3-5 раза меньше, чем хотелось бы. Но статья не про это, а про то, что в сложном проекте, прописать все-все-все требования да так, что бы получилась рабочая система - нереально. Для строительства это научились делать, но это адская стоимость - это примерно как проект 10 этажного многоквартирного дома со всеми коммуникациями (у меня профильная вышка по строительству). Те многократно превышающая доступный бюджет. Ну и как бы и в этом процессе заказчик может решить, что был неправ и надо бы слиться с пейзажем (что в стройке сплошь и радом). И там вот очень очень распространено порционное взаимодействие.
угу, при этом всю дорогу А было А и поменялось из-за какой-то внутренней динамики заказчика, на которую никакого влияния нет
Ну ты че... какой дикпикпик :) Там же написано, что да — без менеджеров и аналитиков и на недорогом проекте, где на них нет денег. Но если че и с менеджерами и с аналитиками будет все тоже плюс-минус самое. Идешь и выявялешь требования и на старте понятно, что будет фейл. Ранее там в комментариях было хорошо указано кем-то, что требования-требованиями, а чел со стороны заказчика, которых хочет их исполнить как требуется и подтверждает это полномочиями и деньгами — вот это задача на стоимость всего проекта. Он даже может и быть, но при этом тебе как подрядчику платить не хочет, или хочет, но как-нить потом в следующей жизни. Че дикпик с этим блин делать будет?
согласен, тыщ 10 — это прям золотой стандарт :)
Я бы предусмотрел передачу каждую неделю или раз в две недели.
Да, есть чуваки (их много) которые предполагают, что если платформа стоит там условно тыщу рублей в месяц, то и месяц работы по проекту ну не дороже 10 тр., да и вообще как-то само должно. Такие отсеиваютсяяв другую сторону.
Это хорошая история, но думаю, что бы в такой форме это было возможно — это бюджет за 15М должен быть. И цель-то всегда будет хорошо сформулирована, она не мешает потом все делать по другому.
Я сейчас придерживаюсь того мнения, что если есть ресурсы и проект большой — 100% делать внутри. Могут быть отдельные технологии внешние, но именно как вещи в себе, а вот эту всю систему взаимосвязей надо генерить внутри, так как любой аутсорс создает адские издержки на коммуникацию — просто кошмарные. нет ничего такого в SAP, что нельзя собрать внутри за разумные сроки и собрать при этом именно так, как нужно. IT-система — это управленческая задача во всех смыслах, успешны те, кто это понял.
Дело в том, что не всегда на старте понятно, что же там надо сделать и заказчику в том числе. Это не проблема — проблема именно в том, что подряд предполагает (и заказчик часто именно так и хочет), что бы затраты на поиск правильной комбинации были переложены на подрядчика. Те эксперементирует заказчик (меняя требования), а выгребать из этого должен подрядчик. Заказчик при этом может быть вполне нормальный, но вот он исходит из того, что я же не разбираюсь в вопросе — мне нужна поэтому конечная стоимость, иначе это будет проект с бесконечными затратами. Какой здесь вывод можно сгенерить — заказчик должен обладать квалификацией сам, что бы заказывать сложное что-то. А если там чуваки «да мы тут не понимаем, это вы специалист» — от таких сразу бежать надо с третьей космической — вот это всегда фейл.
Не, про другое статья, что если кто-то хочет за деньги — то надо настойчиво требовать деньги :) И про то, что если кому-то, что-то нужно в бесплатном продукте — то надо 3 раза подумать делать ли это, так как это запрос от неплатящей аудитории.
Ключевое наверное - это обновление базы и самого приложения. Нельзя просто обновить контейнеры, нужно изменять бд. На втором месте, что требовалось больше инструкций и нам приходилось на каждую фигню писать инструкцию для докера и не для докера, пользователи их обязательно путали. На третьем, что наш докер образ никому не нравился, так как должно же быть все атомарно, как у mailcow - 10 контейнеров и compose. Это уже требует, что бы пользователь был спецом по докер. И в конце стало понятно, что нафиг докер.
В сложных проектах результат зависит также от заказчика, как и от подрядчика. Поэтому когда мы прописываем в договор результат, зависящий от заказчика — ну все, его больше чем в половине случаев не будет (что и видно во всякой разной статистике). Но вообще в таких небольших бюджетах никому не рекомендую брать сложные проекты на разработку — бизнес из этого не получается. Отчасти потому, что определить за короткий срок первоначального обсуждения проекта, что там на самом деле творится у заказчика — нереально. Там все будут очень внимательны и заинтересованы до момента, когда разрабатываемая система начнет реально наступать им на ноги, и где это — дистанционно понять невозможно. Становится понятно через пару месяцев и дальше происходит попадание в инферно. Для того, что бы терпеть его жар и нужны манагеры, ропы, юристы и бухгалтера, что бы можно было организовать там комиссии по заинтересованости и как-то отгородится. Но если у кого-то всей этой ватаги нет, то либо как описано выше, либо проекты максимум до 100 тр за раз и очень важный навык — выключение телефона и игнор (пользоваться придется часто), либо еще можно согласится, что реальная эффективная ставка будет типа 500-600 р./час с квалификацией с которой можно в Сбере чилить с окладом 400К и смузи. Поэтому не получилось у нас сформировать базу подрядчиков, которые бы на заказ проекты делали — там просто никто не выживает, нужно либо сложность проекта меньше раза в 3, либо бюджет больше раз в 5, а такого нет. А когда сами для себя внутри делают — все ок, работает.
Самым безумием в этой истории - это быть веб-студией
А какие модели вы тестировали для оценки полученных документов, если не секрет, и какие были результаты? Спсибо
У них ведущим драйвером была бухгалтерия. У нас тоже есть задумка на 26 год, что будет драйвером массового применения.
Кстати хорошая тема с желающими - когда не два плюс два проект, то и задачи сложные и по факту почти все рассасываются. Что бы кто-то вот прям улучшал проект - это он должен быть ему лично очень нужен в этом улучшенном виде. И потом очень важно, что бы в итоге в коде концы можно было найти. Поэтому проекты, которые разрабатываются сообществами, во первых очень медленно разрабатываются, тратят оргресурсы с КПД парового двигателя и во вторых, внутри часто представляют из себя божественный хаос.
Подписался