Найти тему
Дневник Джуна

Изучаем программирование. День 44. О принципе "Работает — не трожь!" и ещё об одном подобном принципе.

Здравствуйте!

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

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

-2

"Работает — не трожь!"

Так как трудовой стаж у меня большой и поработал я не в одной фирме, я очень много повидал примеров невыполнения этого принципа. Почему это так работает?

1. Бизнес

Самая, наверное, частая причина этого явления — "интересы бизнеса". Почему я написал это в кавычках? Ну потому что в 99% случаев к бизнесу такие "улучшения" никакого отношения не имеют. Пример: работает компания, хорошо работает, приносит прибыль, но неизменно появляется такой человек, которому нужно в налаженном процессе обязательно что-то поменять, чаще всего это какой-то новый человек, либо старый, занимающий высокую должность. И вот он приходит и говорит: делайте теперь вот так, прежний метод не подходит, если вы ему справедливо приводите аргументы и говорите, что предложенный способ не заработает и не будет лучше старого, "главный" человек в отделе/компании говорит: "ты ничего не понимаешь в бизнесе".

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

2. Незнание продукта.

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

3. Новые фукнции.

Это уже ближе к нашему с вами вопросу. Есть у вас на работе, например, внутренняя система отчётности, она работает, не сказать, чтобы идеально, но работает, выдаёт нужные результаты, а сделана при этом абсолютно бесплатно. И тут в компании рождается улучшатель, который говорит, что система эта нам ну никак не подходит и нужно ее улучшить. "Улучшение" возможно в нескольких вариантах: нанимается новый сотрудник, дело которого улучшать, он покупает за огромные деньги систему отчётности, подключает её к внутренней системе, настраивает месяц и в итоге она выдаёт ровно те же результаты, за ровно то же время. Ничего нового не прибавилось, компания потеряла время и деньги. Но после все делают вид, что стало-то всё намного лучше на самом деле. Второй вариант: программистам даётся задание такую систему разработать, выделяются люди, выделяется бюджет и создаётся опять же ровно та же система, но она красиво оформлена и названия немного изменены. При этом компания так же теряет деньги, как и в первом случае. Бывает и такое, что после всех этих "улучшений" всё возвращается к старой системе, в её первозданном виде, потому что работало, но это лучший исход и он крайне редок.

И мы плавно приходим к очень частой ошибке it-компаний, которая вытекает из вышеописанного — "Чинить не там, где сломано".

Очень показателен недавний пример в одной фирме. Имён я называть не буду, чтобы ненароком кого-нибудь не обидеть. Было приложение, работало не без проблем, но работало. Одно время в нём старались что-то исправлять, но потом как-то всё затихло и многие старые раздражающие ошибки так и остались на месте. Но тут приходит новость, приложение решило "улучшиться" — оно сменило имя. Как только я услышал эту новость я сразу сказал жене:"Ну вот и конец пришёл приложению N". Не далее, как сегодя, захожу в Play Market и совсем неудивлённый читаю огромную кучу возмущенных отзывов, которые появились ровно на следующий день после "улучшения". Мало того, что ничего не "улучшилось", так ещё и сломалось там, где до этого работало.

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

К чему я всё это?

Вы вступаете в мир, где вы будете создавать продукты для конечного пользователя, чаще всего это будут бизнес-продукты. Бизнес-продукты приносят прибыль только тогда(если это конечно не какие-нибудь мошеннические продукты), когда они направлены на удобство пользователя, а не когда какой-нибудь самодур, простите, захотел поменять что-то и по его мнению "улучшить". Все вот эти "улучшатели" остались от времён, когда выбора у человека(конечного пользователя продукта) не было и он был вынужден пользоваться одним продуктом. Сейчас выбор у человека есть, но "улучшатели" об этом, видимо, не догадываются. Так вот, прежде, чем принимать решение о будущих изменениях в продукте, проведите опрос, среди сотрудников, среди клиентов, а удобно ли было бы им введение такого улучшения? Принесёт ли оно пользу? В эту ловушку попадаются не только маленькие кампании, но и мастодонты из мира IT, вспомните, например, Windows Vista и Windows 8.

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

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

Как всегда, приятного вам обучения!

Если понравилась статья, поставьте, пожалуйста, лайк! А если вы ещё не с нами, то обязательно подписывайтесь, тут полезно и интересно.

Предыдущая статья ................................................................... Следующая статья.

-3