Comments 19
Жили они долго и счастливо и померли в один день.
Пишите хороший код, а плохого вовсе не пишите (с)
В создании сайтов «сделайте как здесь» чаще всего означает, что клиент абсолютно не хочет задумываться над функционалом и ему кажется, что «как здесь» решит поставленные задачи. И чаще всего ошибается.
Как вообще можно работать с человеком, который не готов описать, что ему нужно и зачем?
Как вообще можно работать с человеком, который не готов описать, что ему нужно и зачем?
Да, есть такое. Но самая жесть начинается, когда «сделать как здесь» звучит из уст не заказчика, а менеджера проектов или аналитика. И, по собственному опыту, как правило за этим стоит либо просто нежелание разбираться, либо карьеризм и интриги — это в самом плохом варианте. При этом PM прекрасно понимает «что и зачем».
особенно «доставляет» когда ты пишешь Х, а тебе говорят сделай как в 1С…
Переменные русскими буквами?.. :)
У меня лет 8 назад был такой случай: один товарищ в конторе любил в коде переменную называть матерным словом. Правда, это было не в 1С, а в VB/VBA, но не суть… Каким-то образом это дошло до начальства — был скандал, приказали искоренить. :) А поскольку товарищ писал много и очень плодовито, то на рефакторинг всего этого хозяйства ушло без малого месяц.
У меня лет 8 назад был такой случай: один товарищ в конторе любил в коде переменную называть матерным словом. Правда, это было не в 1С, а в VB/VBA, но не суть… Каким-то образом это дошло до начальства — был скандал, приказали искоренить. :) А поскольку товарищ писал много и очень плодовито, то на рефакторинг всего этого хозяйства ушло без малого месяц.
Ещё бывает кроме «сделать как здесь», «а как сейчас?»
Ага. И еще «как было раньше», «сами не знаем как» и «чтобы все работало».
«А как сейчас» априори задача совместная — аналитика и программиста. Но отвечает за нее, как правило, в бОльшей степени все-таки аналитик (Project Manager), и от того, насколько качественно он понял и «разрисовал» задачу, по сути, зависит весь проект.
Самое «интересное» начинается тогда, когда ты сделал «сделай очень быстро вон как у Петровича, но чтобы сверкало» и забываешь про этот говнокод «на скорую руку». А потом через пол года-год: «Помнишь ты делал одну штуку для нас, там надо добавить колёсики и что бы всё выгружалось в Excel». А ты уже и забыл как там и что после десятка таких же «хотелок» начальства и снова погружаешься в свой говнокод… печалька.
Не знаю как в остальных конторах, но у нас именно так большинство проектов делается.Времени на то, чтобы подумать «а как было бы лучше» нет.
Не знаю как в остальных конторах, но у нас именно так большинство проектов делается.Времени на то, чтобы подумать «а как было бы лучше» нет.
Вообще нет проблемы сделать «как здесь», просто нужно сразу брать деньги за аудит делать опись функционала под подпись. Оценивать именно то, что вы записали. Вообще обычно вопрос бывает не «сделайте как здесь», а «сколько примерно стоит как здесь». В этом случае клиент все правильно делает, он же не знает сколько это стоит. Ему надо прикинуть, посчитать, стоит ли овчинка выделки. А истеричные Васи и Пети — это уже фантазии ваши.
Мне кажется, для автора это несколько больная тема. Но можно найти довольно много примеров, когда постановка задачи «как там» вполне работает.
Не то, чтобы это лучшая практика, но… довольно много продуктов, например, перешли в опенсорс, потому что разработчики взяли платный продукт и переписав его с нуля, реализовали «как там». И никто из них не жаловался, что нет спецификации.
Когда есть образец, то это очень и очень хорошо, т.к. его можно исследовать и получить информации гораздо больше, чем в самой подробной спецификации.
Риски же, о которых писал автор, все лежат в области что продукт получится не такой, как его задумал владелец продукта. И, наверно, если ВП согласен принять такие риски, то задача «сделать как там», вполне себе имеет место на жизнь.
Тем более, что все остальные аргументы про быдлокод в самой статье, как мне кажется, ни какого отношения к теме не имеют, и имеют аргументацию вида:
1. Ой, а придется же потом переделывать если мы поняли не так. (я чаще видел переделки, когда писались САМЫЕ ПОДРОБНЫЕ СПЕЦИФИКАЦИИ, чем когда они не писались вовсе).
2. Ой, в команде может возникнуть психологическая несовместимость/усталость/конфликт. (Ну может. А может и не возникнуть или возникнуть по любой другой причине.)
Вывод:
1. Если продуктаунер и/или заказчик в команде или оплата у вас идет за время, то такая «спецификация» — довольно неплохой вариант.
2. Если же ваша команда работает за оплату результата, то любой вариант с отсутствием документального и подробного ТЗ — глупость, и как именно вы получили задание — не имеет значения. Все варианты без письменной договоренности — одинаково плохи.
Не то, чтобы это лучшая практика, но… довольно много продуктов, например, перешли в опенсорс, потому что разработчики взяли платный продукт и переписав его с нуля, реализовали «как там». И никто из них не жаловался, что нет спецификации.
Когда есть образец, то это очень и очень хорошо, т.к. его можно исследовать и получить информации гораздо больше, чем в самой подробной спецификации.
Риски же, о которых писал автор, все лежат в области что продукт получится не такой, как его задумал владелец продукта. И, наверно, если ВП согласен принять такие риски, то задача «сделать как там», вполне себе имеет место на жизнь.
Тем более, что все остальные аргументы про быдлокод в самой статье, как мне кажется, ни какого отношения к теме не имеют, и имеют аргументацию вида:
1. Ой, а придется же потом переделывать если мы поняли не так. (я чаще видел переделки, когда писались САМЫЕ ПОДРОБНЫЕ СПЕЦИФИКАЦИИ, чем когда они не писались вовсе).
2. Ой, в команде может возникнуть психологическая несовместимость/усталость/конфликт. (Ну может. А может и не возникнуть или возникнуть по любой другой причине.)
Вывод:
1. Если продуктаунер и/или заказчик в команде или оплата у вас идет за время, то такая «спецификация» — довольно неплохой вариант.
2. Если же ваша команда работает за оплату результата, то любой вариант с отсутствием документального и подробного ТЗ — глупость, и как именно вы получили задание — не имеет значения. Все варианты без письменной договоренности — одинаково плохи.
Sign up to leave a comment.
Техническое задание: почему формулировка «Сделать как здесь» не срабатывает?