×
Фото 5 причин не исправлять "ошибки"

5 причин не исправлять "ошибки"

Сразу оговорюсь, речь пойдёт не о критических ошибках. Если ваш сервис лежит бездыханный, то конечно — ноги в руки и фиксить.

Сразу оговорюсь, речь пойдёт не о критических ошибках. Если ваш сервис лежит бездыханный, то конечно — ноги в руки и фиксить. Здесь разговор пойдёт о "надо бы сделать".

А "надо бы сделать" — это "авгиевы конюшни" IT.

X уже полгода не работает — срочно починить!

В моей практике был отличный пример, когда сломалась группа контролов (управляющих элементов в интерфейсе пользователя). Контролы эти предназначались для модераторов, но узнали о проблеме тестировщики... через несколько месяцев!

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

Спросив у модераторов, узнал, что эти контролы никогда и не были нужны.

Итог — час работы и удаление довольно запутанной логики из проекта, которая и не была нужна.

Меняем название / стиль / страницу!

У каждого изменения должна быть какая-то причина. Казалось бы... К сожалению, это не всегда так. Иной раз это просто работа по-инерции, иной — хотелка дизайнера / менеджера / другого заказчика.

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

Банальным вопросом "а зачем?" можно убрать огромное количество задач на исправление в проекте.

Пользователь не понимает — надо переделать!

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

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

Срочно переверстать X под новые требования!

Часто бывает, что задачи доформулируются в последний момент, что требования меняются.

Не надо заниматься фигнёй. Если прилетели "срочные" правки, то, скорее всего, опять ничего толком не продумали.

Не надо делать двойную работу "в стол". Лучше разобраться: а зачем и почему мы меняем X? А не придётся ли завтра снова всё переделывать?

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

В макете был другой шрифт!

Если вам попался дизайнер, который от страницы к странице сохраняет стиль схожих по смыслу элементов — вы счастливый человек!

Зачастую это не так. У дизайнера есть несколько проектов, под которые он рисует "типа красивые картинки". В этом плане дизайнер — процесс без памяти: он не помнит, какого размера был заголовок на предыдущей странице; не знает, что кнопки у нас на сайте делаются закруглёнными. Он просто делает "типа красиво".

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

Если же прилетают правки "сделать как в макете" — это уже детектор ленивого менеджмента. Он не задумался о макете в разрезе всего проекта. Он просто "лайкнул" картинку.

Вместо итога

Бывают правки, от которых зависит судьба проекта. Это всё то, без чего он не является ценным для пользователя.

Бывают правки, от которых зависит благосостояние компании. Обычно это про деньги, контракты и всяких юристов.

Все остальные правки — не факт, что нужны.

Будь первым – оставь комментарий!

Фото Как обновить git fork (на github)
Предыдущая запись:
Как обновить git fork (на github)
Фото Операционные системы. Linux. Начало
Следующая запись:
Операционные системы. Linux. Начало

Интересное на «Цифре»

Фото «Методологическое безумие» и «Scrum»
«Методологическое безумие» и «Scrum»
Пока в Москве повальное увлечение методологией “скрам” меняется на “бирюзу”, в регионах так и продолжают внедрять “скрам”. Оба эти увлечения обычно не приводят ни к чему хорошему. В конце концов всё приходит к “у нас скрам, но не совсем” или “скрам — говно”
Противление методологиям как методология
Забавное нынче время. Попы освящают дата-центры, детям преподаётся креационизм, а в командах разработки появилось новое обзывательство: “теоретик”
Фото Анти-паттерн "Yes-man" или "Мини-МЫ"
Анти-паттерн "Yes-man" или "Мини-МЫ"
Эх, тяжело одному разваливать проекты! – думаете вы. А тяжело было Иисусу на кресте? Нет! Ведь у него были последователи, апостолы! Ну что же, пора и нам обзавестись оными!
Анти-паттерн "Управление грибами"
Прекрасный анти-паттерн! Прямо всем голова. “Разделяй и властвуй” нашего времени. “Управление грибами”