Pull to refresh

Comments 4

Чтобы понять разработчика, нужно думать как разработчик.
Чтобы думать как разарботчик, надо стать разработчиком.
А для этого надо, как автор правильно заметил, — «читать длинные нудные спецификации».
Не отметайте не глядя даже очевидно ошибочные решения, а обязательно поймите, почему было сделано именно так.

Как быть в случаях, если никакой другой причины, кроме как «так было быстрее / проще / удобнее мне как разработчику это тут влепить»?
Тут суть как раз в том, чтобы понять, действительно ли это так (проще/быстрее/удобнее), или за этим все-таки если какие-то аргументы. Пока вы не выясните наличие/отсутствие и содержание этих аргументов, диалог вести сложно, а тем паче давать рекомендации.

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

Если всё-таки надо дожать, то разрабам можно прописать принудительным просмотр юзабилити-тестирования их творения. Они, конечно, во время просмотра часто матерятся «где вы набрали таких тупых пользователей!!!», но если это не совсем клинический случай, то понемногу действует, на ус мотают.
Only those users with full accounts are able to leave comments. Log in, please.