Pull to refresh

Comments 19

В идеальном мире, всё почти вот так красиво, хоть и сложно. Однако в реальном мире, заказчик по 10 раз переделывает ТЗ на один и тот-же функционал («А мы не знали что так будет»), и очень часто простит несовместимого в новой версии, того что ведёт к усложнению системы ещё больше, либо противоречит тому что было сделано раньше. Объяснить подобное невероятно трудно. Oсобенно, если твои письма и документы не читают, или читают просто проскользив глазами, просмотрев картинки. Но смысла не уловив. Клиповое сознание менеджмента заказчика, — самая большая из бед.
Нечего вам возразить – со всем этим сталкивался много раз. Моя идея в том, что даже в идеальном случае далеко не всё просто.
А если по 10 раз менять требования, то именно из-за вышеупомянутой сложности в смене парадигдмы/метаформы, помимо объективного усложнения, как правило можно встретить и лютое негодование со стороны разработчика.
Ещё известная проблема (Связанная с недостатком опыта и знаний прогера): После реализации очередной фичи, начинается отлавливание багов, что требует в десятки раз больше времени, чем написание этой самой фичи…
UFO just landed and posted this here
Не получилось создать атмосферу распалогающую к размышлению, так как вопросы по детски наивные.
Что значит бюджет завышен? Для чего? Для ПО которое используется в марсаходах или сайтах на php?
И да, я пару предложений только прочел, так как технически это даже на треп не похоже.
Не очень понимаю необходимость таких статей на хабре. Вроде не пятница.
А если уж пофилософствовать, то в т.з. сначала не указывается какой высоты должно быть здание, просто быстро накидать типовой 2-х этажный домик, потому что модульное же всё,
потом добавляются фичи, требующие первым этажом сделать бильярд, второй — парковка, с третьего по двенадцатый — многоквартирки, а ещё в форточку позволить приземлить боинг, а во входную дверь электрички. А парковка (какая б. парковка?) должна правильно выписывать счета припаркованным гироскутерам.
И все эти фичи объявляются не сразу, а поочереди, всё же модульное, а тыжпрограммист должен был быстро типовой домик накидать, крепкий фундамент же не нужен двухэтажке, и лифт не нужен.
А потом спрашивают, а чего так долго данные ворочаются на 12й этаж, и форточку от эирбаса разворотило.

Странно, что это до сих пор обмусоливается, в рамках тостера «этот ответ легко ищется поисковиком».
И мне кажется проблема эта в целом надумана, опытный закзачик, у которого есть опыт N-лет уже понимает стоимость расторопности, и нормально дожидается и готовности, и нормально этапы обсуждает и соглашается парковать боинги и электрички на стоянке.
А перворазы да, наверно не всегда понимают, что сколько стоит и по неопытности налетают либо на кидальщиков либо на студентов. Ибо по теории вероятности им суждено попасть либо в первую кучу либо во вторую, и мал тот шанс, что попадут на адкватного исполнителя, готового внятно объяснить, что дёшево, что дорого и не толкнёт дефолтный опенкарт за 1.5 млн.
Судя по однонаправленности большинства комментариев, к сожалению, я потерпел неудачу в задаче донесения своей мысли.
Основная мысль была не в том чтобы поныть про заказчиков или смену ТЗ, не про то какой подход к организации разработки нужно выбрать и не про бюджеты и их превышения.
А была она про то, из чего состоит сложность разработки в принципе — любого ПО и при любом раскладе.
Думаю всё из-за единственного поставленого во главу угла вопроса.
Вы сами попали в его ловушку и начали вокруг него ходить и, как сусанин, всех завели по нему.
Догадываетесь какой вопрос?

А «сложность» понятие растяжимое, для кого-то комплекс небоскрёбов построить сложно, для другого бытовку поставить сложно. Всё сводится к одному — работать надо и учиться на текущих задачах, главное быть честным и заранее ставить в известность всех, на каких этапах могут быть подвижки по срокам на качественную проработку модуля.

Считаю, что если обе стороны честны друг перед другом, и не пытаются друг друга развести на деньги, ты в принципе вопрос согласования задачи и сложности (+сроки)применения решений достаточно гаромнично решаются. Чего всем и желаю.
разработчики не любят менять свои парадигмы

Поэтому и вот. Проще притянуть статью к своему мировоззрению, чем свое мировоззрение к статье. Не принимайте всерьез мнение людей, которые, прочитав "пару предложений" из статьи, пишут коммент на три ;) 18 человекам, которые добавили статью в закладки, вы все-таки что-то донесли.

Человек предложил пофилософствовать, новое мировоззрение не предлагал. Вроде так.
Теперь вы говорите, что не надо воспринимать всерьёз мнение таких-то таких людей.
ОК, подскажите ещё, чьё надо и чьё не надо воспринимать, я себе помечу, чтобы не ошибиться в следующий раз.

Помечайте. Верить, в наше время, нельзя никому, даже себе. Мне — можно.

Не, хакер не мой источник вдохновения, просто все взяли за шаблон сравнивать строителей, программистов и дятлов.
Дьявол прячется в деталях. И не только в программных проектах. Почему проект просрочен? — потому что недооцен. Почему недооценен? -у «оценщика» не хватило квалификации или опыта. И ПО тут просто частный случай, хотя и типичный
Бывают такие приколы и когда сам себе заказчик и исполнитель. И почему-то всё происходит точно так же будто это два разных человека.
Помню, как-то меня спросили, умею ли я стрелять. Конечно, чё там уметь-то? — ответил я — осталось только попадать научиться.
Так и с разработкой. И со всем остальным.
С завышением и раздутием сроков и стоимости, они же padding, нормальные проектные менеджеры борются с помощью работы с рисками. Составления карты рисков, их постоянного отслеживания и актуализации. Куда все риски с неверно выбранным фреймворком, сложным тестированием и заносятся. А вот как много компаний реально работают с рисками или знают о такой методике — это другой вопрос…
Sign up to leave a comment.

Articles