Как избавиться от привычки усложнять задачу?

Question

[Александр Синицын]

Есть привычка усложнять задачу больше чем надо. Как выработать чувство той границы на которой пора остановиться?

Например, были в таблице два текстовых поля Точка_1, Точка_2, потом мысль пошла... вроде как к полям надо даты... а почему бы их не выделить в отдельную таблицу с полями ID, Text, Date... но у точки есть значение Value... Значение может быть разных единиц измерения... их может быть несколько... Надо справочник единиц измерения... могут быть кг и граммы надо их привести... потом понимаешь, что ещё немного и наступит .опа , а не вернуться ли назад к текстовым полям в которых пользователь может написать все-что ему надо )))

Answer 1

[romy4]

Этот процесс называется определение milestones. Вы сперва определяете MVP (minimal valuable product) — то есть тот уровень завершённости (без рюшечек и плюшек), при котором можно получать выгоду и дальше вы уже строите отталкиваясь от MVP

Answer 2

[Евгений Шатунов]

Лично мне было бы интересно послушать подробности. В данной трактовке вопрос очень сложен из-за своей расплывчатости. :)
Конкретнее! Нужна иллюстрация хода мыслей и критерии, по которым у тебя создается ощущение усложнения задачи.
Так же очень важно понять, сам ты замечаешь усложнение или же тебе говорят об этом.
Александр Синицын , дополни свой вопрос.

Нередко в неадекватном усложнении задачи обвиняют именно те "соратники", кому попросту непонятна ни сама задача, ни ход твоих мыслей. Как правило это результат эффекта Даннинга-Крюгера.

Comments

[Александр Синицын]

Добавил

[Евгений Шатунов]

Александр Синицын , фантазия - штука очень хорошая и безоговорочно полезная. :)
Однако. Увлекаться нельзя. Понимаешь, я сам маялся этим делом с самого начала карьеры. А с ростом проф. уровня мои загоны становились только круче. Строго оговоренный MVP в этом случае решает.
romy4 , пожалуй ближе всего к ответу, т.к. правильно все описал.

Итого, с привычкой усложнять боремся через самоограничение. Работаем не дальше оговоренных рамок задачи. Чувство границы - это тот момент, когда тебе хочется хоть что-то продумать наперед (за пределами MVP) без железно отработанного опыта.

Answer 3

[Петр]

Разбивать задачу на более мелкие и им давать стоимость(временную и финансовую).
Scrum

Answer 4

[Saboteur]

У вас слишком много свободного времени, вот и не знаете куда девать.

Answer 5

[xmoonlight]

Делите на базовый и расширенный функционал.
Базовый - это тот минимум, без которого невозможно пользоваться системой.
Расширенный - то, что можно "навесить" после запуска основного.

Answer 6

[Rou1997]

Слишком мягкие дедлайны? Найдите подработку, вторую, третью, и так пока не станут жесткими! Еще и разбогатеете!
Не хотите богатеть, считаете себя и так достаточно состоятельным? Обратитесь скажем в Даймлер-Бенц, а лучше в Бугатти, и т.п., они вас быстро переубедят!

Answer 7

[Алексей Николаев]

Освоить методологию "ху*к-ху*к и в продакшен". Потом доработаете. Лучше сперва недоделать и получить порцию правок, чем сделать слишком много и потом вырезать ненужное.

Answer 8

[Анатолий]

Вчера читал статью.
Признак квалифицированного специалиста, его способность решать задачу просто.
Учиться и еще раз учиться. Выше TDD советуют, тоже тема! На самом деле, написал код и возрадовался. Через 15 минут, код похудел в три раза. Да будет так! И снова запустил тесты.

Answer 9

[Андрей]

Иногда усложнять нужно. Представь что ты не исполнитель, а заказчик. Задай себе вопрос - стал бы ты оплачивать вот эту повышенную сложность, увеличенные сроки и пр.? Нужны ли они на самом деле, или можно обойтись без них. В конце концов все мы делаем продукты и инструменты, которые должны облегчать жизнь людям, желательно с минимально возможными сроками и бюджетом с максимально возможным качеством и функциональность. Вот нахождение баланса в этой всей истории и есть цель.

Answer 10

[FoxInSox]

Не усложняйте, все ок.

Answer 11

[coodan]

Думаю, учиться. В том смысле, что пока есть время, пробовать и так и эдак. Посмотреть на подводные камни. Найти для себя лучшее решение. А потом воспроизводить его, не задумываясь, на автомате.

Тут ведь такая штука - элегантное решение может показаться слишком сложным, если не созреть до него. А кажущееся простым иметь такие грабли, что потом проще все переписать будет, чем это исправить. Не попробуешь, не созреешь. Ну, например, с той же нормализацией таблиц. Да, их много будет. Кажется, что сложно. Но зато данные целыми будут. Потом проще будет.

Одного не стоит делать - все время переписывать одно и то же когда оно действительно срочно нужно.

Answer 12

[Alexej Simakov]

Полезно пытаться абстрагировать задачу от конкретных вещей ближе к математике. Шелуха килограммами отпадает.

Answer 13

[Дмитрий]

Волшебное слово TDD.
Силы и хитрость тратятся на написание (и отладку!) тестов. На написание кода остаётся ровно то, что нужно, чтобы обзеленить тесты.