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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вместо итога

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

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

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

Также может быть вам интересно:

Как обновить git fork (на github)

Уже некоторое время силами сообщества 900913 переводим tldr на русский – краткие руководства по командам Linux, MacOS и т.д. В октябре за переводы взялись с новой силой – возможно, тому причина hacktoberfest от digitalocean и github.

Читать »

Операционные системы. Linux. Начало

История, философия, общие моменты

Читать »
Фото Пример своей консольной команды в Django проекте

Пример своей консольной команды в Django проекте

Если вы работали с Django проектом, то, скорее всего, запускали команды из консоли (manage.py). В Django есть простой способ писать свои команды для управления проектом.

Фото Панель администрирования Django - подключение, настройка, поиск, фильтрация

Панель администрирования Django - подключение, настройка, поиск, фильтрация

Простой способ подключить админку к сайту на Django, как сконфигурировать адмиин-панель и добавить функциональность поиска, массовых действий, как изменить оформление администраторской панели Django фреймворка.

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

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

Проведённое в США исследование показывает, что далеко не все компании ожидают возвращение к старому образу работы после пандемии.

Фото Что делать, если не успеваешь сделать в срок

Что делать, если не успеваешь сделать в срок

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

Фото Столлман мне друг, но этикет дороже

Столлман мне друг, но этикет дороже

Столлман – активист и лидер GNU, бывший директор Фонда Свободного Программного обеспечения. Кому и почему он неудобен?

Фото Лучше плохо, но сейчас. Взгляд на пути развития ПО

Лучше плохо, но сейчас. Взгляд на пути развития ПО

Сейчас такие языки как Perl и Ruby чувствуют себя не лучшим образом. Но ещё 10 – 15 лет назад они были на "гребне волны".

Фото Сколько стоит программист? Немного очевидного

Сколько стоит программист? Немного очевидного

Какова справедливая ЗП программиста?... И другие смешные вопросы.

Фото Почему асинхронность – это сложно?

Почему асинхронность – это сложно?

Что не так с асинхронностью? Почему программисты и студенты так плохо её понимают?