Не соглашайтесь разрабатывать то, чего не понимаете

[laviol]

Статья неплохая, но заголовок какой-то кликбейтный, ибо понимается по-разному до и после прочтения.

[Scf]

Четвертый уровень понимания, разумеется, "как оно работает". Сеньорные программисты всегда понимают, хотя бы в общих чертах, как устроены их фреймворки и библиотеки и достаточно близко знакомы с их исходниками.

[Grigorenkovic]

Уровней может быть много, для каждой ситуации/проблемы/задачи разное количество. И много взаимосвязей, параметров и условий. В зависимости от решения, которое предложите, могут возникнуть дополнительные требования, условия и даже целые задачи. Бывает, что видна только верхушка айсберга и только постепенно, последовательно можно дойти до корня проблем. Решением может быть отказ от решения, также решением может быть решение совсем других задач, которые влияют на текущее положение вещей. Каждый раз приходится делать выбор: пилить дальше или пилу наточить/другую взять, более подходящую. Постоянно нужно менять фокус для анализа и обнаружения источников возникновения проблем.

[cross_join]

Заголовок анти-аджайловый, на самом деле. Когда на десятом спринте придет понимание, то придет и сожаление, что не сделали сразу «как надо», потеряв кучу времени и ресурсов.

[mayorovp]

Лучше увидеть это на десятом спринте чем через два года...

[cross_join]

Зачем же ждать два года? Эксперт-проектировщик в предметной области (тот самый, с наличием понимания) синтезирует фукциональную архитектуру первого прототипа уже через пару-тройку недель.

[mayorovp]

Это при условии что он есть, эксперт-проектировщик. И при условии что он не ошибется.

[cross_join]

Не хватает своих спецов — пригласите стороннего эксперта. Эксперт, в отличие от вас, уже ошибался, за что ему и платят. Прототипы в спиральных методиках нивелируют риски без карусели спринтов.

[mayorovp]

Сторонний эксперт-проектировщик — смерть для проекта. Потому что он получает деньги раньше, чем становится возможным проверить результат его работы.

[cross_join]

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

[igorch96]

Красиво звучит: гонорар эксперта-проектировщика есть компенсация за перенесенные страдания в результате совершенных им ошибок :)

[cross_join]

Тут скорее вопрос в том, как называть людей, которые не хотят учиться не только на чужих ошибках, но и на своих.

[VolCh]

При аджайле не должно быть больших сожалений в такой ситуации.

[habradante]

Четвертый уровень понимания это какую проблему пользователя или бизнеса оно решает и как. Чтобы потом не пришлось дописывать рядом еще и еще функций, которые, может быть, помогут с, возникшей у пользователя, проблемой.

[JustDont]

Очень жизненная и полезная статья, на самом деле. И да, четвертый уровень понимания — это «а для чего это всё работает?». То есть, какую полезную работу этот код проделывает — для бизнеса, для пользователей, и так далее.

[emmibox]

Пятый уровень понимания: «зачем его вообще было писать»? (в смысле может его уже давно написали другие, и гораздо проще его скачать-купить-украсть… и в итоге получать тот-же результат при значительно меньших затратах для бизнеса)…

[JekaMas]

Отличная статья. Не хватает, по мне, лишь примечания, что иногда задачу проекта еще никто не решил, а копать надо. Проекты бывают и с R&D и кому-то же надо их делать.

[cross_join]

Чтобы решать задачу в R&D нужно хотя бы понимать её суть и быть сильно в курсе других работ по этой теме.

[terrakok]

Статья хорошая, но главное не перегибать, иначе можно дети до того, что "я знаю, что ничего не знаю"

[saipr]

Не соглашайтесь разрабатывать то, чего не понимаете

Вот еще это правило распространить на задания на разработку и тендерную документацию.

[sokol93]

А как же: «как оно вообще работает»?

[m17th]

Я так понимаю вот это есть суть наглядный пример из жизни…

[jetcar]

есть разной сложности проекты, если надо работать с 10 командами которые годами чтото лепили и всё это соединить, то это вовсе не означает что каждый член команды должен знать что делается в других проэктах и как, для этого есть совершенно другие люди которые должны видеть общую картину и при этом понимали как и где в отдельном проэкте что работает

[VolCh]

Очень демотивирует некоторых, работающих над одной частью большого проекта, отсутствие информации о том, что происходит в других частях.