Вхід і реєстрація
Розробка · 14 травня 2021, 21:56 6531
Mykyta Berehulia, Senior Software Engineer в EPAM

Внести собственные улучшения в проекта заказчика? — Нет

Привет! Ищу совет знающих и опытных людей:)

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

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

Я не до конца понимаю почему. Тут же win-win, что не так?

Спасибо!

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Теми: замовник
👍ПодобаєтьсяСподобалось1
До обраногоВ обраному1
LinkedIn

Найкращі коментарі пропустити

Beaver Green 15.05.2021 11:51

Меня это то же удивляло по-молодости. На первом проекте опытный синьор учил меня как правильно делать новые фичи: берем файлы исходников, КОПИРУЕМ ЦЕЛИКОМ, переименовываем классы методы и тогда меняем. Т.е. если у нас был класс PriceCalculator1 то копируем и делаем класс PriceCalculator2 и потом в нужном месте ставим ветвление какой класс вызывать.
Я тут же начал возражать что дублирование кода — это плохо, надо рефакторить, наследовать, декомпозировать и т.д.
На это он привел железные аргументы:
1) Ты уверен что точно знаешь как работает класс PriceCalculator на 10 000 строк? Нет? Так никто из команды уже не знает!
2) Класс PriceCalculator покрыт юнит тестами или любыми другими тестами, которые проверят что после изменений ничего не сломалось? Нет!
3) У тебя есть документация, которая описывает текущий алгоритм расчета цен, новый алгоритм и правила когда что применять? Нет!
4) Если ты поменяешь хотя бы одну строку в существующем классе PriceCalculator1 — как ты убедишься, что из 100500 клиентов, которые используют разные комбинации скидок и т.д. ни у одного не поменяется цена товаров? А какой скандал будет если все-таки поменяется ты понимаешь?
Ты хочешь сделать что-то новое? Делай так что бы оно 100% не повлияло на старое. Потому что в большом проекте невозможно проверить где и что отвалиться.
Любой рефакторинг, улучшение производительности, переход на новые версии, даже исправление явной ошибки в коде или прочие идеи, которые могут предложить девелоперы, для клиента означает потенциальные проблемы с валом звонков от недовольных юзеров у которых что-то начало работать не так, как раньше!
Предположим девелопер очень хорошо разобрался в бизнесе клиента и предлагает какую-то не чисто техническую фичу. Которая, к тому же, не повлияет на существующий функционал. Ну, например, прикрутить на сайт чат-бота. Даже если девелопер сделает это абсолютно бесплатно — это все равно новый функционал, который нужно: релизить, тестировать, мониторить, чинить, интегрироваться и т.д. Т.е расходы все равно будут. А вот будет ли от этого какая-то прибыл — неизвестно. Если юзеры не просили эту фичу, если бизнес аналитики ее не предлагали — то какая вероятность что это вообще кому-то нужно?
Посмотрите сколько возможностей в больших продуктах (например MS Word) и про сколько из них не знает и никогда не использует 99% пользователей! От «мертвых» фич такой же вред, как от мертвого кода.
Поэтому девелоперам и не дают ничего улучшать в проекте по своей воле. Если есть желание покреативить — то лучше сделать отдельный прототип и показать его клиенту. Возможно ему понравиться и тогда уже он, оценив все плюсы и минусы, выделит оплачиваемое время на разработку, тестирование, интеграцию, поддержку и обучение юзеров этой новой фиче. И если прототип девелоперы напишут за пару выходных, то внедрение этой фичи в продукт — это уже вопрос немалых денег!
P.S. Это извечная проблема: работаешь на дядю — делаешь что прикажут. Хочешь творчества — пили бесплатно опенсорс или стартап (скорее всего получится то же бесплатно).

Перейти до дискусії
Igor Protsenko 17.05.2021 12:43

Привносить свои улучшения в проект клиента/заказчика можно и нужно! Но есть большое НО. Это нужно делать корректно и в этом процессе есть огромное количество нюансов.
1) Если ты часть аутсорс команды, то в первую очередь такое улучшение нужно согласовать со своим ПМ/ДМ. Возможно твоя идея очень крутая и ее можно продать как upsell клиенту. Клиент будет рад, что команда проявляет инциативу, клиенту будет польза о внедрении нужной фичи, менеджмент аутсорс компании получит профит от дополнительной прибыли от upsell, менеджмент аутсорс компании будет рад повышению репутации в глазах клиента.
Но этот путь тернист, не прост и длителен по времени.
После того, как ты предложишь, а затем продашь свою идею ПМ/ДМ, эта идея будет взвешена и оценена менджментом с вовлечением дополнительных ресурсов (аналитиков, архитекторов, продактов и тд). После этого идея будет в корректном виде озвучена клиенту. После этого, если клиент даст добро — будет определена команда, которая займется дополнительным анализом реализации этой фичи, оценкой ее имплементации и внедрения. И только после последующих согласований — эта фича будет передана в разработку. При этом она может быть передана в разработку не тебе, а другой команде, которая будет на взгляд клиента или менеджмента наиболее целесообразной для реализации данной фичи.
2) Если ты часть продуктовой компании — задача немного упрощается, но все равно есть целый ряд упражнений, через которые нужно пройти прежде, чем что-то оптимизировать.
Для начала нужно обсудить свое предложение со своим Product owner или если такого нет — со своим лидом или ПМ.
После того, как ты предложишь, а затем продашь свою идею, ее анализом займется либо PO, либо ответственный аналитик, после оценки этой фичи, если она будет актуальна — ее оценят с точки зрения business value и соответствия целям компании. После этого фича будет приоритезирована и запланирована в работу наиболее подходящей команде для имплеметации и опять это ее непосредственной имплементацией вероятно будешь заниматься не ты.

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

Перейти до дискусії
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Владислав Фурдак CTO в Nearshore Devs 19.05.2021 23:37

— Вы уверены что это реально улучшиния ?
— Если да, то какие риски они переркывают ? Актуальны ли риски для заказчика ? Не создадут ли ваши улучшиения еще бОльшие риски ?

Відповісти
Підтримати
Ivan Skvortsov Head of Infrastructure Unit в N-iX 18.05.2021 19:35

про Эффект Даннинга — Крюгера уже писали в комментариях?

upd: по CTRL+F не нашел, ну буду первым тогда :)

Відповісти
Підтримати
Grez 18.05.2021 02:19

Аутсорс это не то место где самостоятельно делать улучгения. Если хочца драйву — то надо валить в продукты.

Відповісти
Підтримати
Bogdan Shyiak SE or Dev 18.05.2021 11:27
Если хочца драйву — то надо валить в продукты.

Стартапи

Відповісти
Підтримати
Grez
Андрей Литвинов C Señor 18.05.2021 21:46

Стартап — это как раз то, место, где можно непостредственно принимать участие в создании легаси!

Відповісти
Підтримати
anonymous
Grez 19.05.2021 14:09

Как известно хороший код отличаеться от плохого только фактом написания собой недавно.

Відповісти
Підтримати
Андрей Литвинов
Андрей Литвинов C Señor 19.05.2021 15:11

А легаси от нелегаси — наличием тестов 🙂

Відповісти
Підтримати
Grez
Андрей Литвинов C Señor 19.05.2021 23:39

Согласен, маленького пука достаточно :)

Відповісти
Підтримати
anonymous
Armin Van Tubin 19.05.2021 15:42

Хороший код какает в лоток, плохой — по углам

Відповісти
Підтримати
Grez
Мамкин АЙПИшник 17.05.2021 18:08

Культура труда в Тойота в 2000х была байка что: если за два года работы на одном месте работник не вносит на рассмотрение специального отдела новшество оптимизируещее его непостедственный труд. Его увольняют с *волчьим билетом* — как не лояльного, или не обладающего должной квалификацией.
Это не та песня конечно, но мотив явно похожий.

Відповісти
Підтримати
Dmytro Hovdia Senior Software Engineer Java 17.05.2021 18:19

Ну мы ведь о IT говорим. «Взрослым дядям» пофигу на то что продукт сделан из г*уна и палок, до тех пор пока это косвенно не влияет на их прибыль.

Відповісти
Підтримати
Мамкин АЙПИшник
Мамкин АЙПИшник 18.05.2021 22:56

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

Відповісти
Підтримати
Dmytro Hovdia
Dmytro Hovdia Senior Software Engineer Java 18.05.2021 23:35
Проблема в том что влияет

это решает заказчик а не гребец со стороны.

Відповісти
Підтримати
Мамкин АЙПИшник
Sergey Lysak T/T Lead 19.05.2021 08:46
Теорию эволюции пока никто не опроверг.

What’s the largest amount of bad code you have ever seen work?
news.ycombinator.com/item?id=18442637
answer: Oracle Database 12.2.

рус itpravda.com/...​/oracle-25-million-lines

Відповісти
Підтримати
Мамкин АЙПИшник
Grez 19.05.2021 14:13

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

Відповісти
Підтримати
Мамкин АЙПИшник
Dmytro Hovdia Senior Software Engineer Java 17.05.2021 17:08

Всё просто — «Инициатива наказуема» и не будет никем оценена.

Відповісти
Підтримати
Dmytro Barsukov Senior java developer в EPAM 17.05.2021 15:24

Поддержу других комментаторов: стоимость фичи для бизнеса — это не только ее разработка. Поэтому если витдите, что можно улучшить, то лучше предложить и обосновать чем же она хороша (вот тут бывает что нужно какое-то MVP набросать, но MVP, а не то что можно будет в master залить). А там уже как решит продукт овнер. Может даже оказаться что с точки зрения бизнеса это не улучшение, а наоборот — размывает фокус продукта и им сложнее пользоваться.
А вот в рамках фичи обычно (если это не махровый аутсорс) предложения приветствуются. Не технические чуваки часто не понимают всех импактов и трудозатрат. Поэтому докопаться для чего они хотят эту фичу и предложить свой вариант может быть хорошим решением. Которое встретит поддержку. Вот тут win — win.
Но рассуждения выше — это если исходить из того, что нужно продукту. К сожалению по моему опыту делать то что лучше для продукта часто приводит к стратегии win — fail для себя. Подтянуть можные подходы и технологии намного легче на пет проекте. А на зарплату инициативность и боление за продукт влияет отрицательно — ты и так мотивирован, зачем тебе платить больше. Но это по моему опыту. Очень надеюсь, что это мне не везло.
И наверное стоит подчеркнуть — выше это про инициативность и фичи. Качество работы и техническую часть я считаю что в любом случае стоит делать хорошо. Это и честно и полезно для себя, как программиста. Что именно считать хорошим в каждом отдельном случае — это отдельный вопрос, на который не всегда можно дать правильный ответ, но с опытом приходит понимание где можно забить костыль, а где надо потратить время и продумать архитектуру.

Відповісти
Підтримати
Dmytro Krasucki 17.05.2021 14:03

От уявіть собі. Ви приганяєте своє авто на СТО. Кажете майстеру, що тре робити. На другий день приходите забирати, а він каже: «Я те, що ти хтів, зробив. А потім в мене ще був вільний час, тому я твого двигуна 2.2 викинув та поміняв на п’ять літрів V12 (в мене зайвий був, ніде його використати), то тобі безоплатно та від щирого серця, бо так же ж воно краще поїде...»
А вам, наприклад, п’ять літрів нафіг не потрібно, бо вам важливіше за все була економність...

Відповісти
Підтримати
Slava Bilokur Android Developer в Amofintech 17.05.2021 13:00

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

Відповісти
Підтримати
Igor Protsenko Entrepreneur and Product manager 17.05.2021 12:43

Привносить свои улучшения в проект клиента/заказчика можно и нужно! Но есть большое НО. Это нужно делать корректно и в этом процессе есть огромное количество нюансов.
1) Если ты часть аутсорс команды, то в первую очередь такое улучшение нужно согласовать со своим ПМ/ДМ. Возможно твоя идея очень крутая и ее можно продать как upsell клиенту. Клиент будет рад, что команда проявляет инциативу, клиенту будет польза о внедрении нужной фичи, менеджмент аутсорс компании получит профит от дополнительной прибыли от upsell, менеджмент аутсорс компании будет рад повышению репутации в глазах клиента.
Но этот путь тернист, не прост и длителен по времени.
После того, как ты предложишь, а затем продашь свою идею ПМ/ДМ, эта идея будет взвешена и оценена менджментом с вовлечением дополнительных ресурсов (аналитиков, архитекторов, продактов и тд). После этого идея будет в корректном виде озвучена клиенту. После этого, если клиент даст добро — будет определена команда, которая займется дополнительным анализом реализации этой фичи, оценкой ее имплементации и внедрения. И только после последующих согласований — эта фича будет передана в разработку. При этом она может быть передана в разработку не тебе, а другой команде, которая будет на взгляд клиента или менеджмента наиболее целесообразной для реализации данной фичи.
2) Если ты часть продуктовой компании — задача немного упрощается, но все равно есть целый ряд упражнений, через которые нужно пройти прежде, чем что-то оптимизировать.
Для начала нужно обсудить свое предложение со своим Product owner или если такого нет — со своим лидом или ПМ.
После того, как ты предложишь, а затем продашь свою идею, ее анализом займется либо PO, либо ответственный аналитик, после оценки этой фичи, если она будет актуальна — ее оценят с точки зрения business value и соответствия целям компании. После этого фича будет приоритезирована и запланирована в работу наиболее подходящей команде для имплеметации и опять это ее непосредственной имплементацией вероятно будешь заниматься не ты.

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

Відповісти
Підтримати
Igor Lytvynenko Co-Founder в Artellence 18.05.2021 12:17

Ви написали, в цілому, може й вірно. Але я б не хотів працювати в компанії з таким підходом. Занадто багато бюрократії. До того ж ви описуєте самий довгий шлях, а подаєте його як найкоротший.

По нормальному, якщо фіча в сфері компетенції цієї команди — достатньо винести на дискусію на найближчому мітингу. А там вже вирішується яких stakeholder-ів є сенс залучати.

Якщо ж в сфері компетенції іншої команди — знайти їх ліда і «продати» ідею туди.

Якщо ж фіча десь на межі ( щось там з апі, наприклад ), то можна обговорити на мітингу і якщо ок, то одразу йти чи самому чи з лідом до іншої команди чи до «найменшого спільного кратного», де приймається рішення.

Взагалі, якщо рішення приймаєш не ти, то є сенс одразу йти до того, хто його приймає ... і чим менше «посереднків» тим краще. А там вже вирішиться чи треба там аналітик/дизайнер чи ні.

Ну і якщо це зовнішній клієнт, треба дивитись на те як організована робота в цілому. Можливо є сенс продати фічу клієнту одразу і на рівні «виконавець-виконавець» і потім вже підняти її на рівень sales. Але знову ж ... по обставинам.

Відповісти
Підтримати
Igor Protsenko
Артем Перекресний WTF over SSH 18.05.2021 13:32

Будь-яку зміну треба розглядати не в єдиній точці, де вона власне відбудеться, а в усьому виробничому циклі. Грубо кажучи, рацуха по перенесенню дирочки в корпусі двигуна на 5 см вліво може давати покращення в одній операції, але вимагатиме перерозрахунків міцності, переробляння форм для литва, заміни оснастки, перенавчання працівників конвеєру, заміни технологічних карт та інструкцій, і бозна ще чого. І у більшості випадків виграш від «покращення» не покриває витрат у всьому циклі. І тому так, всі згідні, що так було б краще, але ніхто не стане того робити, і не затвердить такі зміни.

На жаль, будь-який проект в процесі реалізації костеніє та втрачає гнучкість. Рішення, прийняті на початку, жостко лімітують подальший розвиток, і, подеколи, струнка та естетично довершена ідея в процесі реалізації перетворюється на гидку потвору. В більшості випадків з тим нічого не вдієш.

Відповісти
Підтримати
Igor Lytvynenko
Igor Lytvynenko Co-Founder в Artellence 18.05.2021 14:27

Ви все вірно кажете... такі випадки бувають. І тут щоб щось змінити, потрібна тверда «політична воля».

Моя ж теза полягає в іншому: далеко не кожен рух здатен порушити крихку рівновагу проекту. І рішення є сенс приймати як можна простішим способом (що в більшості випадків є можливим ... тим більше в IT).

Для того, щоб проект розвивався, ініціативу потрібно заохочувати. Це дуже наївно вважати, що хтось розумний може «сісти і придумати» гарний продукт/рішення/архітектуру. В багатьох випадках проблеми вилазять при безпосередній реалізації. І хочете чи ні, а якість придуманої архітетури найкраще бачать ті самі прості розробники.

Відповідно, чим легше і швидше ідеї будуть «вспливати» — тим краще для результату. Звісно, що це не має бути хаотично, але це має бути просто та швидно, а не складно і з купою бюрократії.

Відповісти
Підтримати
Артем Перекресний
Артем Перекресний WTF over SSH 18.05.2021 18:23
якість придуманої архітетури найкраще бачать ті самі прості розробники

Я вас благаю.
Простий розробник бачить лише спек на модуль та інтерфейси, і навряд чи уявляє собі, що відбувається поза межами його групи. «Проблеми реалізації», здебільшого, викликаються нюансами архітектури, про які «простий розробник» навіть не здогадується. Ну, там, масштабування, або інтеграційні нюанси, або легасі, або вимоги по безпеці, і ще купою інших речей. Причому деякі з цих факторів є зовнішніми і не можуть бути змінені аж ніяк.

І увесь «бюрократизм» викликаний не палкою любов’ю керівництва до субординації та обкладання папірцями, а намаганням дати раду складності сумі всіх умов та обмежень, яких необхідно дотримуватись.

Повертаючись до аналогії з двигуном, завжди є можливість десь, замість передбаченого проектом каленого болта М4, якого нема на складі, вкрутить саморіза, який на складі є. І воно таки буде працювати. Певний час. Поки різьбовий отвір під болт не розіб’ється у вульгарну дирку. Так, подібне «покращення» дозволить випустить в строк кілька тисяч двигунів і зекономить кілька копійок на болтах, але потім неминуче почнуться проблеми з підтримкою продукта, рекламаціями, репутаційними втратами, а подеколи все закінчується банкрутством та вильотом з ринку не тільки продукту, але й усього бізнесу.

Відповісти
Підтримати
Igor Lytvynenko
Igor Lytvynenko Co-Founder в Artellence 18.05.2021 21:58
бачить лише спек на модуль та інтерфейси

В нас з вами трохи різний досвід. Як на мене, розробник має знати свою частину детально, а решту хоча б поверхнево (включаючи деплой, вимоги і бізнес задачі).

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

намаганням дати раду складності сумі всіх умов та обмежень

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

Відповісти
Підтримати
Артем Перекресний
Мамкин АЙПИшник 18.05.2021 23:14

Просто нужно правильно ставить приоритеты. Безопасноть для продукта или продукт для безопасности?

Відповісти
Підтримати
Igor Lytvynenko
Артем Перекресний WTF over SSH 18.05.2021 23:17
В нас з вами трохи різний досвід. Як на мене, розробник має знати свою частину детально, а решту хоча б поверхнево (включаючи деплой, вимоги і бізнес задачі).

Це аджайл-досвід, так?

Відповісти
Підтримати
Igor Lytvynenko
Igor Lytvynenko Co-Founder в Artellence 18.05.2021 23:42
Це аджайл-досвід, так?

Думаю, можна так сказати.

Відповісти
Підтримати
Артем Перекресний
Артем Перекресний WTF over SSH 19.05.2021 02:34

Уявіть собі, що мені архітектор, ландшафтний та інтер’єрний дізайнери розробили проект за моїми вподобаннями. Якось так, наприклад:
www.buildingplanner.in/...​s/ready-plans/34N1001.jpg
І ось я наймаю декілька бригад — бетонувальників, мулярів, штукатурів, електриків, сантехніків і так далі. І починаю будувати будинок своєї мрії. І ось вже близиться фініш

І тут штукатур, від якого мені потрібно лише рівні поверхні стін, починає критикувати колорістичні рішення, пропонує замість італійської плитки кинуть лінолеум, і висловлює принципову незгоду з розстановкою меблів... Фінал дещо передбачуваний, чи не так?

В аджайлі клієнт сам до пуття не знає, чого хоче. Розробник робить і показує. Клієнт погоджується — робиться наступний крок. Не погоджується — попередній крок переробляється. В аджайлі розробник приймає рішення і робить вибір. Клієнт лише погоджує чи завертає ці рішення.

У вотерфолі розробник робить лише те, що йому кажуть. Від забору до обіду. Так, як сказано, там де сказано, з того, з чого сказано. Всі рішення прийняті ще до початку будівництва. Увесь вибір зроблено іншими людьми. Думка виконавця щодо вибору рішень нікого не цікавить. Йому платять виключно за рівні площини.

Відповісти
Підтримати
Igor Lytvynenko
Igor Lytvynenko Co-Founder в Artellence 19.05.2021 08:38

Нещодавно робив ремонт ... ви знаєте ... це ще той agile )))

Тут ми зараз знову ж можем кожен наводити свої історії ... Електрик, наприклад, може зауважити, що десь варто кинути іншого перерізу провід, бо проектний буде грітися... чи, наприклад, запропонувати на ванну поставити додатковий ПЗВ (і бажано поставити більший щиток). Сантехнік може сказати, що туалет занадто далеко від стояка і «з цим треба щось думати». Штукатур може сказати, що десь порушена геометрія кімнати ... тощо.

Не обов’язково з усіма погоджуватися ... але почути це варто і осмислити чи є сенс щось міняти, поки не пізно.

Waterfall має свої недоліки. Тому й придумали agile. Як на мене, навіть коли все продумано від початку до кінця, є сенс звертати увагу на обставини по ходу. В готовому будинку ще одну розетку доставити важко ... але в 99% випадків дуже хочеться.

Та й ось SpaceX показує, що agile застосовний навіть в галузях, де був waterfall десятиліттями... в них ж кожен запуск starlink-а — це як спринт ... щоразу новий білд і нова модель супутника. І, як виявляється, воно життєздатне.

Відповісти
Підтримати
Артем Перекресний
Igor Lytvynenko Co-Founder в Artellence 19.05.2021 08:58

Ну ... кругом є межа ...

Якщо «тут в тебе труба прорвала ... ми її підлатали щоб не текла ... що з нею далі?» — то це більш ніж ок.

Якщо «ми тут вікно на іншу стіну перенесли, бо в сусіда злий собака» — звісно що не ок і треба було обговорити.

Відповісти
Підтримати
anonymous
Igor Lytvynenko Co-Founder в Artellence 19.05.2021 10:45

Ми тут ходимо по колу )) І дискусія вже трохи поплила від оригінальної теми.

Моя теза полягає в тому, що потрібно притримуватись в цьому питанні якогось здорового глузду.

Тихо пиляти фічу тиждень і нікому не казати — НЕ ок.

Зробити за дві години якийсь експеримент/proof of concept/рефакторинг (без мержа в мастер) і потім винести на дискусію (бо натхнення прийшло) — цілком ОК.

Мої коментарі вище — це не так оцінка того, що ТС пише, як реакція на те, що коментатори пропонують сидіти і не висовуватися.

Ініціатива — це круто і вірно і це треба заохочувати, а не подавляти.
Звісно, що це має мати межі здорового глузду і робитися «при світлі дня», а не «під столом, поки ніхто не дивиться».

Відповісти
Підтримати
anonymous
Oleksandr Viter Senior Software Engineer в SoftServe 17.05.2021 12:23
но как бы это и не то что нужно заказчику

Это, в данной ситуации, ключевое (если, конечно, вы не ошиблись в формулировке и не имели в виду что-то совершенно иное).
Если что-то не нужно заказчику или просто имеет низкий приоритет, по сравнению с остальными задачами — то и делать это не нужно.

Также учтите, что для плодотворной работы, ментального здоровья и т.д. нужно соблюдать work-life balance, а значит — никаких активностей в свободное время, тем более бесплатно)

Відповісти
Підтримати
Леонид Мартынюк инженер-программист в 1World online R&D Сenter 17.05.2021 12:01

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

Відповісти
Підтримати
Мамкин АЙПИшник 18.05.2021 18:36

Работает не трогай = хз как оно работает => недостаток квалификации, имно, конечно же.

Відповісти
Підтримати
Леонид Мартынюк
Леонид Мартынюк инженер-программист в 1World online R&D Сenter 18.05.2021 18:39

ЗАКАЗЧИК знает как оно работает раз он с этим работает. а не умник програмист не понимающий предметную область

Відповісти
Підтримати
Мамкин АЙПИшник
Мамкин АЙПИшник 18.05.2021 18:45

То вы еще убийцу фейсбука не делали наверное. Или файловый 1с на 50 юзеров.

Відповісти
Підтримати
Леонид Мартынюк
Уставший архитектор 19.05.2021 10:58
ЗАКАЗЧИК знает как оно работает

Разные ситуации есть..................................

Відповісти
Підтримати
Леонид Мартынюк
Молдавский Узбек 17.05.2021 11:14

Тут про один из аспектов последствий улучшений хорошая дискуссия
habr.com/ru/post/557678

Відповісти
Підтримати
Full Stackly 16.05.2021 15:40

Это касается не только разработки: «лучшее — враг хорошего». Чтобы убедиться достоверно, что персональное видение правильного — не гарантия правильного, надо написать собственный проект и всраться... ну или преуспеть, тогда тем более зачем вкладывать душу в какой-то чужой бизнес, если можно самому сделать и снять сливки.

Відповісти
Підтримати
Володимир Корнійчук Senior Software Engineer (C++) в Infopulse, Part of Tietoevry Create 16.05.2021 15:16

Пиши юніт-тести. Ніхто не насварить за зайвий тест, його не треба тестувати/деплоїти, а значить ти не витратиш ресурсів інших членів команди. Ти не зламаєш нічого на продакшені і через тебе замовнику не будуть телефонувати злі користувачі. Окрім того, таким чином можна краще зрозуміти продукт. І ще можна знайти помилку і показати її вже не просто під соусом «мені тут захотілося порефакторити», а в контексті «ось такий юніт-тест падає, давайте виправимо?». Всіх, хто радить не лізти з ініціативою взагалі — не слухай. Якщо нікуди не лізти — то нікуди і не вилізеш. Просто лізти треба обережно.

Відповісти
Підтримати
Андрей Литвинов C Señor 16.05.2021 18:43

С тестами тоже нужно быть осторожным. Некоторые могут сильно замедлять CI, другие — ломаться при малейшем рефакторинге, когда поведение системы не меняется. К тестам тоже нужно с умом подходить.

Відповісти
Підтримати
Володимир Корнійчук
Володимир Корнійчук Senior Software Engineer (C++) в Infopulse, Part of Tietoevry Create 17.05.2021 10:00

Рівень небезпеки від погано написаного тесту все-одно в рази нижчий. Кінцевий користувач продукту не прийде бити морду. А сповільнений CI — ну, то таке. Рефакторинг, що зламав тести? Так це ж взагалі пісня! Якщо тест мав якийсь сенс, а рефакторинг його зламав — то це помилка у рефакторингу і наявність тесту пішла на користь, оскільки не дала зробити дурницю. Той, хто робить такий рефакторинг, має бути вдячний тому, хто написав тест.

Відповісти
Підтримати
Андрей Литвинов
Андрей Литвинов C Señor 17.05.2021 10:55

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

Рефакторинг, по определению, — изменение имплементации без изменения поведения. Если поведение не меняется, а тесты начинают падать — это признак хрупких тестов (brittle tests). Негативная сторона — увеличение стоимости поддержки, потому что помимо продакшен кода нужно еще поддерживать тучу тестов. Опять же, спроси почему это плохо, если неочевидно.

Відповісти
Підтримати
Володимир Корнійчук
Evgeniy Sokolov Principal Developer в Solaris Tech UA 17.05.2021 12:13

Ваши аргументы схожи с аргументами людей, которые не пристегивают ремни безопасности в авто: «А мой знакомый выжил в аварии, только потому, что не был пристегнут ремнем (например, выбросило из машины, а остальные погибли в ней). Поэтому не нужно пристегивать ремень»
Статистика правда говорит об обратном.

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

Но большинство согласится, что в большинстве случаев лучше, чтобы тест был, чем его не оказалось.

Відповісти
Підтримати
Андрей Литвинов
Андрей Литвинов C Señor 17.05.2021 12:37

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

Відповісти
Підтримати
Evgeniy Sokolov
Володимир Корнійчук Senior Software Engineer (C++) в Infopulse, Part of Tietoevry Create 17.05.2021 13:41

Так а де хто казав писати неякісні тести? Звичайно, що потрібно писати якісні. Мова йшла про рівень небезпеки і відповідальності від коду умовного джуна, доданого з власної ініціативи в продакшн або в тести. Я б, напевне, в 99% відхилив таку ініціативу для продакшена, але в більшості випадків погодився б на розширення набору тестів.

Відповісти
Підтримати
Андрей Литвинов
Андрей Литвинов C Señor 17.05.2021 13:48

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

Відповісти
Підтримати
Володимир Корнійчук
Stefan Vodicska 17.05.2021 12:22

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

Відповісти
Підтримати
Андрей Литвинов
Андрей Литвинов C Señor 17.05.2021 12:40

Тесты гонялись круглосуточно, потому что было много merge request-ов? Или потому что прогнать тесты занимало сутки?

Відповісти
Підтримати
Stefan Vodicska
Stefan Vodicska 17.05.2021 12:51

Много реквестов. Да и тестов под миллион

Відповісти
Підтримати
Андрей Литвинов
under 17.05.2021 13:03
Всіх, хто радить не лізти з ініціативою взагалі — не слухай. Якщо нікуди не лізти — то нікуди і не вилізеш. Просто лізти треба обережно.

Не совсем так.
Надо калибровать обратную связь от менеджера и менять свое поведение соответственно.

Расскажу пример из жизни.
На одном моем проекте поощрялось спорить, отстаивая какую-то позицию (по техническим вопросам). Если не отстаивал — то считалось отсутствием инициативы, безвольностью и токсичностью.
Потом я перешел на другой проект, и когда начал применять поведение с предыдущего проекта — то менеджер мне довольно скоро тактично намекнул, что со мной сложно работать.
Я откалибровал этот момент, и с тех пор стал делать только то что просили, 0 инициативы и 0 споров.
Все последующие годы менеджер давал мне performance review «exceeds expectations» и моя ЗП выросла x1.5. Украинский филиал спустя 5 лет попал под сокращение, но меня уволили в числе последних.

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

Відповісти
Підтримати
Володимир Корнійчук
Dmytro Lapshyn Solution Architect 17.05.2021 15:29
Ніхто не насварить за зайвий тест

Видел примеры обратного, когда заказчик предъявлял в весьма эмоциональной форме претензии за часы, потраченные на написание тестов по инициативе команды. Причём, «градус вопроса» там был десятки часов максимум.

Відповісти
Підтримати
Володимир Корнійчук
Володимир Корнійчук Senior Software Engineer (C++) в Infopulse, Part of Tietoevry Create 17.05.2021 23:59

Дивлячись на якому етапі то робити, звичайно. Якщо «десятки годин на тести» були витрачені в першому спринті командою з двох людей — замовника можна зрозуміти :) Я радив з огляду на ситуацію топікстартера — великий проєкт, давно йде, багато людей, хочеться розібратися і щось покращити. Шанси конфлікту з замовником — мінімальні.

Відповісти
Підтримати
Dmytro Lapshyn
De Money 16.05.2021 15:13

В мене один із взагалі життєвих принципів — не робити добро, поки не попросять. Інакше — це саме ті благі наміри, які до пекла ведуть. Можна спитати, чи не треба допомога, і тоді попросять, якщо треба. Можна от запропонувати, як ви зробили і розпитати, чому ні. Можна таки зробити самому, але тоді усвідомлювати, що робиш це тільки для себе і нікому більше воно потрібно не буде (найімовірніше) і запросто будуть ще й пручатись. І тоді треба ще уважно дивитись, щоб не нашкодити, ну і розуміти, навіщо воно вам.

Відповісти
Підтримати
Гастрафет Аристархович 16.05.2021 14:00

Я в такій ситуації зазвичай звільняюся. Працювати від паркана до обіду — ну його в дупу.

Відповісти
Підтримати
Олексій Пєніє 16.05.2021 15:45

Так і запишемо, Микиту Бондаренка — на звільнення.

Відповісти
Підтримати
Гастрафет Аристархович
Геннадий Зяблицев 16.05.2021 13:07

Если ты просто бодрый джун, которому хочется быстрей опыт набить, то:
1. Улучши.
2. Протестируй.
3. Удали
Воспринимай это как задачки с литкода.

Відповісти
Підтримати
PKCLsoft 16.05.2021 16:54

Важное уточнение — «в свободное от работы время»

Відповісти
Підтримати
Геннадий Зяблицев
Alexey Lopato QA manager в Indeed 16.05.2021 11:40

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

Відповісти
Підтримати
Artem Kurakin software engineer в Microsoft 17.05.2021 10:42

Если от каждого ждать апрува, то задолбаешься ждать.
Победителей не судят.

Відповісти
Підтримати
Alexey Lopato
Artem Kurakin software engineer в Microsoft 17.05.2021 11:05

Ты просто зануда

Відповісти
Підтримати
anonymous
Roman Pavlyuk myself в ELEKS 16.05.2021 10:37

Я так колись отримав свого першого закордоного замовника

Відповісти
Підтримати
Андрей Литвинов C Señor 15.05.2021 23:09

Кстати, почитав комменты, я так и не уловил твою мотивацию. Для чего это тебе?

Відповісти
Підтримати
Андрей Литвинов C Señor 15.05.2021 23:16

Такой подход может здорово помочь прокачаться. Если компания этого не ценит, можно двигать дальше со временем. Но нужно понимать свою ответственность за подобные решения и согласовывать это с бизнесом. Нужен баланс между подходами better safe than sorry и наборот, зделать что-то принципиально полезное и извиниться, что потратил на это время.

Відповісти
Підтримати
anonymous
Андрей Литвинов C Señor 15.05.2021 23:21

Может, просто не повезло с проектом/командой/компанией?

Відповісти
Підтримати
anonymous
Mykyta Berehulia Senior Software Engineer в EPAM 16.05.2021 00:13

Интересно. Больше интересных задач — больше опыта, больше опыта — больше интересных задач:)

Відповісти
Підтримати
Андрей Литвинов
Андрей Литвинов C Señor 16.05.2021 09:57

Да, все верно. Если в компании подобные инициативы не проходят, тогда можно смотреть в сторону open-source. С pet-project сложнее, потому что не все доходят до прода и целый пласт задач просто не всплывает. Или, как уже говорили, leetcode + system design :)

Відповісти
Підтримати
Mykyta Berehulia
Андрей Литвинов C Señor 16.05.2021 18:47

В проде появляются новые проблемы поддержки, изменение, масштабирования. Чаще в запущенных проектах они уже есть, а в pet-проектах с ними может вообще не придется столкнуться.

Відповісти
Підтримати
anonymous
Андрей Литвинов C Señor 17.05.2021 15:06
Так что посыл их не делать я не понимаю.

Надеюсь, тебе не показалось, что он исходил от меня.

Может ты любитель решать задачи аля "Починить то, что в продакшне будет плохо работать".

Я сторонник изначально делать так, что бы в продакшене работало хорошо.

Відповісти
Підтримати
anonymous
Андрей Осипов 15.05.2021 22:56
Естественно я загорелся желанием в свое свободное время сесть и сделать их.

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

Відповісти
Підтримати
Олексій Пєніє 15.05.2021 23:40

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

Відповісти
Підтримати
Андрей Осипов
Olena Sharovar Senior Software Engineer (Billing) in a startup 15.05.2021 22:54

Кроме тех аргументов что уже приводили — делая что-то бесплатно, вы не даете своей компании возможность сделать upsale (продать дополнительные услуги или +1 человека в команду). Поэтому это и не приветствуют (се ля ви). Сделать немножко лучше — приветствуется, это называется going the extra mile. Но делать прям много всего заказчику бесплатно (там где компания могла бы продать еще услуг или людей) это вы у компании отбираете хлеб вообще-то.

Відповісти
Підтримати
Олексій Пєніє 16.05.2021 08:43

Почему нет? Улучшения тоже бывают малобюджетными, вплоть до полной копипасты. А что такое «мало» — бывает же как в анекдоте про еврея, когда денег у него в обрез.

Відповісти
Підтримати
anonymous
under 15.05.2021 21:43
Естественно я загорелся желанием в свое свободное время сесть и сделать их.

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

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

Відповісти
Підтримати
Мамкин АЙПИшник 15.05.2021 20:02

Когда вы поймете *что не так* станете токсичным. Или как раньше говорили циником.
По сути, проблема в *софтскилах* — т.е. донести ценность улучшения не в ваших силах.
Конечно же, еще проблема часто в компании, и её миссии — если это банальный способ заработать себе на новую ламборгини, попутно кинув всех по привычке. То нужно тихо гребсти пока ЗП не задерживают и все(о чем ниже не раз, и не два, написали).
Часто клиент и так похож на быка которого с коровой перепутали 8). По этому за фичу никто не заплатит.
Если абстрагироваться, то тенденция брать (почти)синьеров на мидловые/джуновские позиции(по экспертизе) и заливать их баблом именно к этому и ведет. (Человеку скучно работать, и он придумывает как развлечься, лучший все равно думает о том как улучшить свою работу).

Відповісти
Підтримати
Рахіт Срінавасович Кумар 15.05.2021 18:57

в проектах стартапного типа со временем тебя могут услышать и оценить

Відповісти
Підтримати
anonymous
Рахіт Срінавасович Кумар 15.05.2021 17:41

ты не архитектор проекта и подрываешь авторитет авторитетам
знай свое место
если идея хорошая ее могут присвоить а тебя сократить

Відповісти
Підтримати
Олексій Пєніє 16.05.2021 08:45

Ты веришь что у всех проектов есть архитектор? Или хотя бы у 10%?

Відповісти
Підтримати
Рахіт Срінавасович Кумар
Andrey Rogovsky Допомагаю знайти першу роботу IT для Трейні та Джунів в TOPIZDATO: Соціальна IT-екосистема 15.05.2021 17:27

Коментар порушує правила спільноти і видалений модераторами.

Andriy Vorobyov フルスタック侍 15.05.2021 17:04
Я погрузился в рабочий проект и чаще замечаю вещи, которые мог бы улучшить. Естественно я загорелся желанием в свое свободное время сесть и сделать их.

Делать это в свободное время — плохая идея.

Можно предложить улучшение, поговорить с продакт овнером и менеджментом, если им нравится и они согласны — они могут создать таску/задачу для этого.

И уже в контексте этой таски/задачи можно делать улучшения.
В рабочее время.

Відповісти
Підтримати
Oлександр V 15.05.2021 17:12
В рабочее время.

В час який трекається та оплачуться

Відповісти
Підтримати
Andriy Vorobyov
Рахіт Срінавасович Кумар 15.05.2021 17:43

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

Відповісти
Підтримати
Andriy Vorobyov
Andy Pandy 15.05.2021 18:21

Точно не дивиденды, а ещё один проектик в нагрузочку за те же деньги, хорошо ведь справляешься

Відповісти
Підтримати
Armin Van Tubin
Рахіт Срінавасович Кумар 15.05.2021 19:00

тогда запоминаешь этот факт и начинаешь копать в интересном тебе направлении (много или мало)

Відповісти
Підтримати
Andy Pandy
Рахіт Срінавасович Кумар 15.05.2021 18:58

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

Відповісти
Підтримати
Armin Van Tubin
Andriy Vorobyov フルスタック侍 16.05.2021 04:48

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

А так людей которые овертаймят бесплатно по собственному желанию и на галерах хватает.

Відповісти
Підтримати
Рахіт Срінавасович Кумар
Slava Snezhkov Software Engineer 15.05.2021 16:18
в свое свободное время сесть и сделать их.

Тестировщик тоже теперь должен будет найти свободное время чтобы подтвердить что эти улучшения улучшают?

Відповісти
Підтримати
Sergey Lysak T/T Lead 15.05.2021 15:39
чаще замечаю вещи, которые мог бы улучшить

Бывает да.
Кто еще согласен с этими пунктами:
1 вы можете
2 улучшить
?

Естественно я загорелся желанием в свое свободное время сесть и сделать их.

Сделайте.
Начните с нечто вроде статьи-плана-тех задания
1. Сейчас вот так
2. Это плохо, потому что а) б) в)
3. Если сделать так и так — будет хорошо
4. Потому что а) б) в)

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

да, — внезапно — это точно не то что нужно.
Кто-то должен прочесть или послушать ваше мнение.

Если вы его написали, — то даже когда откажут — вы сможете сделать с этого статью. для своего блога, доу, медиума/dev.to

будет — польза вам даже больше чем если вы сделаете фичу.

Тут же win-win, что не так?

Пока никакого win-win не видно.

Ничего личного, но из моего опыта — самые самоуверенные архитекторы — среди джунов.
И уверены что за выходные все перепишут — тоже джуны.

В вашей истории не хватаете главного — рациональных подробностей :)

Желание улучшить конечно похвально. Проактивность, вовлеченность — это отлично!
А вот самодеятельность когда вы в команде — уже не очень хорошо.

Відповісти
Підтримати
Олег Дорожко 15.05.2021 15:33

Заметил улучшение? Может быть — провидел? Как провидец? Не знаешь?
Подожди какое-то время. Если замеченное имплементируется, значит — провидел, значит — провидец. Никому об этом не хвастайся. Чаще всего провидение мешает, так как провидцы опережают время имплементации. Из-за чего и страдают.
Проще всего перепутать все планы, это увидеть какую-то имплементацию, обстоятельства для овеществления которой еще не наступили.
Поэтому инициатива — наказуема.

Відповісти
Підтримати
Yriy Ivakhnenko 15.05.2021 14:44

молодость она такая, потом как прилетит тебе за твое улутщение, — сразу перестанеш дурней страдать.

Відповісти
Підтримати
Андрей Литвинов C Señor 15.05.2021 23:09

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

Відповісти
Підтримати
Yriy Ivakhnenko
Denys Ievstratenko Senior Java Developer 15.05.2021 13:56

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

Відповісти
Підтримати
Vladyslav Melnyk 15.05.2021 13:58
когда сделать
в свое свободное время
Відповісти
Підтримати
Denys Ievstratenko
Denys Ievstratenko Senior Java Developer 15.05.2021 23:08

Ну там же не только ресурсы разработчика могут понадобиться

Відповісти
Підтримати
Vladyslav Melnyk
Denys Ievstratenko Senior Java Developer 15.05.2021 23:09

Нет, но общение помогает понять, как они мыслят. Многие очень даже не против инициативы ещё и бесплатно, но нужно изначально обговорить

Відповісти
Підтримати
anonymous
Vladyslav Melnyk 15.05.2021 13:19

Инициатива е*ет инициатора:) Это классика, пару раз тебя прокидают с твоими предожениями, ты задемотивируешься и будешь сидеть хладнокровно делать унылые таски в 3 раза дольше чем обычно — посматривая ютубчик:)
Велкам ту зе клаб!

Відповісти
Підтримати
Roman Gorodishcher Principal Engineer в Twilio 15.05.2021 12:39

Вспоминается классика от Лебедева.

Відповісти
Підтримати
Oлександр V 15.05.2021 13:06

Класика у тьоми татьянича — це вкрасти і видавати за своє

Відповісти
Підтримати
Roman Gorodishcher
Beaver Green 15.05.2021 11:51

Меня это то же удивляло по-молодости. На первом проекте опытный синьор учил меня как правильно делать новые фичи: берем файлы исходников, КОПИРУЕМ ЦЕЛИКОМ, переименовываем классы методы и тогда меняем. Т.е. если у нас был класс PriceCalculator1 то копируем и делаем класс PriceCalculator2 и потом в нужном месте ставим ветвление какой класс вызывать.
Я тут же начал возражать что дублирование кода — это плохо, надо рефакторить, наследовать, декомпозировать и т.д.
На это он привел железные аргументы:
1) Ты уверен что точно знаешь как работает класс PriceCalculator на 10 000 строк? Нет? Так никто из команды уже не знает!
2) Класс PriceCalculator покрыт юнит тестами или любыми другими тестами, которые проверят что после изменений ничего не сломалось? Нет!
3) У тебя есть документация, которая описывает текущий алгоритм расчета цен, новый алгоритм и правила когда что применять? Нет!
4) Если ты поменяешь хотя бы одну строку в существующем классе PriceCalculator1 — как ты убедишься, что из 100500 клиентов, которые используют разные комбинации скидок и т.д. ни у одного не поменяется цена товаров? А какой скандал будет если все-таки поменяется ты понимаешь?
Ты хочешь сделать что-то новое? Делай так что бы оно 100% не повлияло на старое. Потому что в большом проекте невозможно проверить где и что отвалиться.
Любой рефакторинг, улучшение производительности, переход на новые версии, даже исправление явной ошибки в коде или прочие идеи, которые могут предложить девелоперы, для клиента означает потенциальные проблемы с валом звонков от недовольных юзеров у которых что-то начало работать не так, как раньше!
Предположим девелопер очень хорошо разобрался в бизнесе клиента и предлагает какую-то не чисто техническую фичу. Которая, к тому же, не повлияет на существующий функционал. Ну, например, прикрутить на сайт чат-бота. Даже если девелопер сделает это абсолютно бесплатно — это все равно новый функционал, который нужно: релизить, тестировать, мониторить, чинить, интегрироваться и т.д. Т.е расходы все равно будут. А вот будет ли от этого какая-то прибыл — неизвестно. Если юзеры не просили эту фичу, если бизнес аналитики ее не предлагали — то какая вероятность что это вообще кому-то нужно?
Посмотрите сколько возможностей в больших продуктах (например MS Word) и про сколько из них не знает и никогда не использует 99% пользователей! От «мертвых» фич такой же вред, как от мертвого кода.
Поэтому девелоперам и не дают ничего улучшать в проекте по своей воле. Если есть желание покреативить — то лучше сделать отдельный прототип и показать его клиенту. Возможно ему понравиться и тогда уже он, оценив все плюсы и минусы, выделит оплачиваемое время на разработку, тестирование, интеграцию, поддержку и обучение юзеров этой новой фиче. И если прототип девелоперы напишут за пару выходных, то внедрение этой фичи в продукт — это уже вопрос немалых денег!
P.S. Это извечная проблема: работаешь на дядю — делаешь что прикажут. Хочешь творчества — пили бесплатно опенсорс или стартап (скорее всего получится то же бесплатно).

Відповісти
Підтримати
Oleg Korol POWER Ops, again 15.05.2021 15:38
Ты уверен что точно знаешь как работает класс PriceCalculator на 10 000 строк? Нет? Так никто из команды уже не знает!

и как итог, вместо одного — ДВА таких класса

Відповісти
Підтримати
Beaver Green
Олексій Пєніє 16.05.2021 08:52

И просто адовое количество ошибок, когда вместо одного прописали другой — и всё ж работает! И тесты проходятся на ура.

Відповісти
Підтримати
Oleg Korol
Beaver Green 17.05.2021 11:40

А потом три и и т.д. Как бы глупо это не выглядело — но это снижает риск возможных последствий. Если внести изменения в старый класс, который используют тысячи пользователей — наверняка хоть у кого-то поломается. Если делать новый фичи в новом классе — то это повлияет только на тех нескольких пользователей, которые попросили эту новую фичу.
Если кто не знает IE умер именно потому, что в каждой новой версии IE были режимы для всех предыдущих версий!
Итог таких гнилых энтерпрайзов известен: приходит конкурент с новым блестящим продуктом, который не тормозит из-за старого кода и юзеры постепенно сбегают к нему.
Чисто психологический эффект: скажи юзерам что мы в новой версии передвинем кнопку — они будут вопеть «вы сломали мне жизнь!», «верните как было!». Покажите юзеру новое приложение с совсем другими кнопками — и он будет говорить что оно лучше и как ему было неудобно на старом (хотя он сам требовал ничего не менять!). И его даже не будет смущать что новое приложение не умеет половины того, что умело старое — оказывается что без этого тоже норм.
Думаю это одна из причин почему постоянно появляются новые приложения. Намного дешевле написать новую версию «с нуля», чем годами поддерживать старое, гнилое приложение. К сожалению многие клиенты не понимают этого — и тратят деньги на «мертвую лошадь», в то время как рядом их конкуренты пилят «убийцу».

Відповісти
Підтримати
Oleg Korol
Dmytro Barsukov Senior java developer в EPAM 17.05.2021 15:38

Вот собственно это и приводит к тому, что дешевле написать новую версию.
Безоглядно лезть и менять класс в таком жестком легаси, конечно, нельзя. Но добавить еще кучу копипасты ОЧЕНЬ бысто убъект проект. Когда пришли и попросили поменять 1 мелочь во всех флоу, а это не в 1 месте, а 5 в каждом классе. А классов уже 3. И каждый живет своей жизнью и никто не скажет все ли флоу ты нашел.
Поэтому такой «опытный синьор» отлично может страховать себя от увольнения — кроме него в этом бреду никто не разберется. Но если даже уже есть такой монстр класс стоит попробовать донести бизнесу всю жесть положения и получить время на разгребание тех долга. Хотя те кто довели до такого состояния проект вряд ли будут готовы признавать ошибки и уж тем более публично перед бизнесом

Відповісти
Підтримати
Beaver Green
Roman Pavlyuk myself в ELEKS 17.05.2021 23:35

В нас були десятки копіпаст, зроблених різними індусами в різний час.

Бобер часом не індус? Чи ми вже деградували викреслено просвітлилися до їхнього рівня двадцятирчної давності?

Відповісти
Підтримати
Dmytro Barsukov
Dmytro Barsukov Senior java developer в EPAM 17.05.2021 23:45

Именно так. Зарплаты стали существенно выше, чем в других сферах и вместо гиков, которым в кайф программировать приходят те кто хочет только зарплату. А поскольку кадровый голод, то берут кого угодно вне зависимости от умений. Ну и «маємо те що маємо».
Индия прошла это раньше. Мы проходим сейчас.

Відповісти
Підтримати
Roman Pavlyuk
N K 18.05.2021 16:11

Ті хто хочуть тільки зарплату в ІТ, походу ще й Commodore в дитинстві не бачили!
Як таких можна допускати до коду взагалі?

Жах!

Відповісти
Підтримати
Dmytro Barsukov
Мамкин АЙПИшник 18.05.2021 18:41

К коду, убийцы розетки за 2 мес, нормальный инженер и так не полезет. Остальным нужны софт-скилы чтоб зепку с тонущего судна вытащить.

Відповісти
Підтримати
N K
Олег Дорожко 15.05.2021 15:47
Даже если девелопер сделает это абсолютно бесплатно — это все равно новый функционал, который нужно: релизить, тестировать, мониторить, чинить, интегрироваться и т.д. Т.е расходы все равно будут. А вот будет ли от этого какая-то прибыль — неизвестно. Если юзеры не просили эту фичу, если бизнес аналитики ее не предлагали — то какая вероятность что это вообще кому-то нужно?

Очень точно замечено.

Відповісти
Підтримати
Beaver Green
Владимир Кожаев 15.05.2021 15:57

Бобёр, ты странный. Какие-то новые идеи бизнесу, за бесплатно!?! А болтецкий он не лососнёт?! Моя задача пилить код, с утра и до обеда. С минимальной производительностью, чтоб только не выгнали и оставалось время на свой бизнес.

Відповісти
Підтримати
Beaver Green
Beaver Green 17.05.2021 11:41
Какие-то новые идеи бизнесу, за бесплатно!?! А болтецкий он не лососнёт?! Моя задача пилить код, с утра и до обеда.

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

Відповісти
Підтримати
Владимир Кожаев
Владимир Кожаев 17.05.2021 19:22

А зачем ты на работу тратишь больше трёх часов в день?

Відповісти
Підтримати
Beaver Green
Владимир Кожаев 18.05.2021 13:52

Так легче поменяться самому, чем поменять мир под себя. Нет?

Відповісти
Підтримати
anonymous
Max Ischenko Founder в DOU.ua 15.05.2021 16:26

Если на каждую фичу создавать 10 тыс строк копипасты, то и за деньги мне кажется долго не проработать. Наверное до первого вменяемого code review.

Відповісти
Підтримати
Beaver Green
Bot Bot 15.05.2021 22:45

Там где классы по 10К строк там апприори нет

вменяемого code review

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

Відповісти
Підтримати
Max Ischenko
Beaver Green 17.05.2021 12:03

Это основная проблема всех больших проектов, которую я видел неоднократно.
Когда первый раз пишут класс вроде PriceCalculator — в нем несколько сотен строк. Это новый проект, у нас аджайл, поэтому времени что бы выносить интерфейсы, все покрывать тестами, писать комментарии и документацию нет. В аджайле рулит KISS и «само-документирующийся» код...
Потом добавляется новое правило пересчета. Ну не будут же вместо одного if в коде делать рефакторинг и применять какие-нибудь паттерны? Воткнут if и в лучшем случае напишут 1 строку комента зачем. Потом юзеров становится больше — каждый хочет свои скидки, свои правила — ветвлений становится все больше. Через полгода в классе PriceCalculator уже несколько тысяч строк.
И вот тут уже пора его рефаторить, разбивать на подклассы, выносить стратегии или вообще делать workflow с заделом на будущее расширение... НО шанс уже упущен! Даже если сам рефакторинг не слишком сложный — то риски колоссальные. И что бы убедиться что ни у кого ничего не сломается потребуется масса тестирования (каждое ветвление в коде удваивает число вариантов)! При этом для клиента все это не несет никакого business value — только риски.
Ни один ПМ не сможет уговорить клиента за такое заплатить!
Ну и все — с этого момента код начинает «гнить»: вставляют костыли, делают дублирование что бы ничего не сломать, изначальные авторы покидают команду и еще через год-два в классе PriceCalculator 10 000 строк и никто не знает всего, что они делают.
Я вижу единственный путь как с этим бороться: овер-инжениринг. Если делаем PriceCalculator и знаем что правил может стать больше — то сразу наворачиваем максимально гибкое решение. Например workflow с пайплайнами и жесткими интерфейсами для правил. После этого следим что бы этот дизайн никто не «расширил», сделав все паблик и напихав правил по тысяче строк.
Но это противоречит идее аджайла и желанию клиента и ПМа быстро получить MVP и потом его расширять. Такой подход сейчас любят клиенты.
По-мне это выглядит так: давайте сначала построим киоск, а если бизнес пойдет — то потом надстроим сверху еще 100 этажей! Хотя и дураку понятно что если хочешь когда-нибудь получить небоскреб то для начала нужно заложить фундамент, который его выдержит.

Відповісти
Підтримати
Bot Bot
Victor Mikhaylov junior manual tester 17.05.2021 12:31

нормальные девелоперы (как мы :-) ) при добавлении новой фичи, если существующий код «не масштабируется», делают сразу рефакторинг. и это сделать легче пока оно еще не разрослось до 10000 строк. для нефункциональных изменений в нашем срам процессе есть «технический спринт» в последнюю неделю-две перед релизом, когда у девелоперов работы по написанию кода нет. идет регрессия и код фриз, добавлять ничего нового нельзя, тестеры тестируют, девелоперы в это время занимаются заделом на будущее

Відповісти
Підтримати
Beaver Green
Roman Pavlyuk myself в ELEKS 17.05.2021 23:36

До першого фічереквесту, який складніший, ніж підправити кілька констант.

Але теоретикам тут видніше...

Відповісти
Підтримати
Max Ischenko
Roman Pavlyuk myself в ELEKS 16.05.2021 10:13

Сіньйор був індусом?

Бо ми щось таке потім колись переписували, після того, як до цього стало неможливо дописувати фічі.

Відповісти
Підтримати
Beaver Green
Dmitry K Tech Lead/Architect в IT Company 17.05.2021 12:09

Интересный «senior» подход. Я думаю, что так долго не продержаться. Как минимум есть метод — red-green refactoring, если верно было написано, что данная функциональность покрыта unit тестами. Отрефакторил, прогнал и вперед. Вот так, собственно, код и бронзовеет — таким образом превращаясь в отвратительный легаси. Все потому что — по простому и побыстрее. Чтобы потом было время на что-то другое.

Відповісти
Підтримати
Beaver Green
Beaver Green 17.05.2021 14:39
функциональность покрыта unit тестами. Отрефакторил, прогнал и вперед

Такое работает только в теории. На практике даже если 100% строк кода покрыто юнит тестами — это абсолютно не гарантирует что его можно безопасно менять!
Потому что для 100% гарантии нужно покрыть не только 100% строк, но и перебрать все возможные варианты входных данных. Вот, на вскидку для банального метода с одним числовым параметром:
— положительное число, отрицательное, ноль
— целое или дробное
— варианты 9.999999 или 0.00001
— числа на 0.5 или 0.555555 (округление математическое или лас-вегас)
— числа, которые дают результат «в периоде» 1.3(3)
То есть на 1 функцию с 1 параметром нужно написать несколько десятков тестов! А если параметра 2 то это уже сотня тестов (все комбинации).
Понятно, что абсолютно никто так не делает. Пишут 1-2 теста. В итоге любое элементарное изменение в коде может привести к тому, что какая-то из не-проверенных комбинаций начнет возвращать немного другой результат.
Например, в теории a/c + b/c == (а+b)/c. А на практике округление может дать отличие где-то в 4 знаке после запятой. И это будет заметно, например, только на заказах от 10 000. Найдет клиент это случайно через пол-года и скажет «а верните-как мне с каждого заказа те 50 центов, которые из-за вашей ошибки недосчитывало». Понятно что воранти и все такое — но формально-то он прав: из-за вас он потерял деньги!
Поэтому и существует пресловутое правило «работает — не трогай»! Ну или если оно же в виде SOLID принципа:
Open for extension, Closed for modification(!).
В идеале один раз написанный и проверенный код должен никогда потом не меняться! Но что бы так работало — нужен очень правильный дизайн, с мелкими «кирпичиками» с слабой связностью. И его нужно проектировать сразу, а не резать монолит потом.

Відповісти
Підтримати
Dmitry K
Stefan Vodicska 17.05.2021 14:58

Тут вот и пригодится test driven development, когда входные данные получают и утверждают c product owner (ну или как оно там называется) :)

Відповісти
Підтримати
Beaver Green
Sergey Lysak T/T Lead 17.05.2021 15:07

таких подробностей реализации продакт овнер часто и не знает, и не должен знать.
если кто и должен, помимо программиста, так QA

Відповісти
Підтримати
Stefan Vodicska
Stefan Vodicska 17.05.2021 15:31

Зачем подробности реализации? Надо знать при каких входных данных какие результаты должны быть на выходе. Это как раз область знаний продакт специалиста (в моём понимании).

Відповісти
Підтримати
Sergey Lysak
Sergey Lysak T/T Lead 17.05.2021 15:32
Надо знать при каких входных данных

продакт овнеру?
а что еще должен знать такой Господь Бог — вместо программиста?

Это как раз область знаний продакт специалиста (в моём понимании).

это понятно что вы о своем понимании.

а в моем понимании программист обязан быть способным проанализировать «арифметику»
и т.д.
в моем понимании запросы у «программистов» идут к тому что другие обязаны в сторону:
вы мне пришлите такие ТЗ и спеку, такой детализации, чтобы я смартом сфоткал, и в IDE вставил
А IDE пусть распознает, и «гугл транслейтом переведет».

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

Відповісти
Підтримати
Stefan Vodicska
Stefan Vodicska 17.05.2021 16:00

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

Відповісти
Підтримати
Sergey Lysak
Sergey Lysak T/T Lead 17.05.2021 16:23
А если нет «арифметики» и надо тупо иметь специфический опыт в предметной области

так в книгах и пишут что, программист увеличивает свою ценность в компании, в проекте, когда у него появляются знания домена :)

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

абстрактному программисту:
тупо спецификацию, где почти код написан, да лид три раза пояснит, и т.д.

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

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

всяко бывает.
тестами да, задницу тогда себе прикрыть полезно. :)
а процентом покрытия и лид с пиэмом прикроют себе.
полезное дело :)

ну и похоливарить на темы кодер vs программист, кто такой мидл, а кто такой синьор, вовлеченность, продукт ориентированное мышление, тупо нехватку времени, потому что еще три критикал таски и т.п.

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

Відповісти
Підтримати
Stefan Vodicska
Sergey Lysak T/T Lead 17.05.2021 16:36
Вон на той неделе

у нас баг всплыл, на проде

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

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

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

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

А поди ж ты...
В итоге — списание дважды (нарыл у одного пользователя — 7 раз списало!)

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

И вот, давайте юнитестами выловим.
Покроем ими на 99,9% код.

а, и продакт овнера отпинаем!
чего он в тз/спеке не написал, как надо писать код??
и лида, как он так ревьювал, а?

Відповісти
Підтримати
Stefan Vodicska
Sergey Lysak T/T Lead 17.05.2021 15:06

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

из чего неверно делать вывод что они не нужны, юнит тесты.

Но польза от их наличия вот в этом:

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

да, вот если б такой дизайн, то может быть и ловили бы они существенное.

Поэтому и существует пресловутое правило «работает — не трогай»!

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

а то вот три маленьких латочки
1 от программиста А,
2 потом на его латочку программист Б добавил,
3 потом бажик мелкий фиксал программист В, и тоже, аккуратненькую латочку поверх этих двух.
Тесты зеленые — все ок!

а под этими латочками тааааакой дефектище припрятан!
Дефект как следствие из:
«Ни одну проблему нельзя решить на том уровне сознания, на котором она была создана»

Конечно, по всякому бывает, есть сроки, есть опыт их срыва, есть объемы кода(и только овертаймить? а оно тебе надо?), есть управляемость-прогнозируемость разработки, ..., ...
it depends...

Но, проекты в которых строго следуют правилу — «работает — не трогай» в итоге и станут проектами где тронь что — получишь ядреный взрыв. по крайней мере треть закрытых тасок перейдут в статус reopened :)

Відповісти
Підтримати
Beaver Green
Андрей Литвинов C Señor 15.05.2021 10:26

Если это решение техдолга, изменение имплементации, которая не влияет на поведение и ускоряет команду или улучшает процесс, то норм, конечно. При условии, что есть peer review. Если это фичи, которые влияют на бизнес, то обязательно нужно согласовывать с Product Owner-ом перед началом подобных изменений, как уже объясняли.

Відповісти
Підтримати
Yevhen Kushnir 15.05.2021 09:32

Питання не розкрито.
Якшо твій код потрапив на production, то виникає питання — а шо це за компанія, де кожен джун має доступ до prod-а? Якшо ж не потрапив, то історія мала б обірватися ще на етапі code review.

Пройде кілька років і ти взагалі ніколи нічого не будеш робити без відповідної задачі в jira.
Все нормально, це приходить з досвідом.

Відповісти
Підтримати
Андрей Литвинов C Señor 15.05.2021 10:22
а шо це за компанія, де кожен джун має доступ до prod-а?

Netflix?

Відповісти
Підтримати
Yevhen Kushnir
Yevhen Kushnir 15.05.2021 10:30

Якшо девелопери +/- одного рівня, то без проблем. Але якшо іде явна градація на junior/senior, то не думаю, шо це хороша ідея.

Ну, і як там в Netflix?

Відповісти
Підтримати
Андрей Литвинов
Андрей Литвинов C Señor 15.05.2021 10:35

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

Відповісти
Підтримати
Yevhen Kushnir
Yevhen Kushnir 15.05.2021 10:41

Ну, шо я можу сказати? У мене досвід абсолютно протилежний.
Хоча сама ідея, коли в кожного є доступ до прода — мені імпонує.
Процеси рішають все, тут без варіантів.

Відповісти
Підтримати
Андрей Литвинов
Mykyta Berehulia Senior Software Engineer в EPAM 15.05.2021 11:15

Конечно, я говорил не о внесении внезапных изменений в production код, это уже совсем ниндзя техники :D

це приходить з досвідом.

Да, этим и занимаемся.

Відповісти
Підтримати
Yevhen Kushnir
Bot Bot 15.05.2021 09:01

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

Відповісти
Підтримати
Oлександр V 15.05.2021 13:39
Это с какой радости?

Це коли в автора кода его дуже спітніле і розпухше
Тіки тронь і гній поллється

xD

Відповісти
Підтримати
anonymous
Dmytro Gladkyi 15.05.2021 08:52

Це можна робити лише при умові: працюєш в продукті (а ніякі скотобази галери) та вище керівництво дійсно зацікавлене в цьому.

Якщо в скотобазі: взагалі не бачу сенсу щось педалить їм на шару (хоча теж грішив так), плюс своєю активністю на фоні того сміття, що працює поруч, ти всіх будеш підставляти і станеш токсичним.

Якщо в продукті: зроби 1×1 з вишами, покажи їм працююче демо свого покращення, покажи, що якщо для них ОК: то зроблю ще це і це, але уже в робочий час (ключовий пункт). Якщо дають добро — то їм це дійсно треба і цікаво. Якщо кажуть, що тільки у вільний час — миттєво забий. Бо тебе почнуть доїти.

Я от зробив іноваційний продукт всередині продукту, уже другий рік його розробляю :-)

Відповісти
Підтримати
Stefan Vodicska 15.05.2021 04:28

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

Два примера из опыта:
— В аутсорсе: приходилось усмирять архитекта на стороне исполнителя, который верещал что «такой подход не потянет миллион запросов, давайте все переделаем». Задача подразумевалась на максимум 20 000 запросов (в той области не было и не предусматривалось больше пользователей). И проект и бюджет были спланированы соответственно задаче. В итоге — все работает до сих пор, хоть и прошло лет десять.

— В продуктовом стартапе: я нашел серьезную ошибку в процедуре импорта данных (потеря целостности) когда исследовал проблему со скоростью импорта. Обсудил эту ошибку с head of engineering (который пришел на проект со мной в одно время), получил добро на добавление валидации (не давал вставить некорректные данные), имплементировал и... получил по шапке.

Оказывается, единственного пользователя продукта всё устраивало. Они потом руками допиливали данные, и разумеется, мы им поломали привычный процесс. Хотя делали «как лучше».

Відповісти
Підтримати
Armin Van Tubin 15.05.2021 01:38

Заведи себе гитхаб и строгай в свободное время отвлеченные от проекта поделки там. Или контрибьють в опен-сорц если так в свободное время кодить неймется

Відповісти
Підтримати
Олексій Пєніє 15.05.2021 00:56

Всё правильно сказали. Твоё дело посоветовать, заказчика — принять решение. Вот только мой совет, никогда не предлагай бесплатно если это не какой-то пустяк.

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

Ну и ещё момент: лучшее — враг хорошего. Может заказчик просто не хочет рисковать тем, что уже работает, и совсем не уверен что твоё покращення взлетит без багов.

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

В остальном же — просто забей. Ты не собственник продукта и НИЧЕГО не получаешь от его хорошей работы. Найдётся другой заказчик, который оценит. Ты будешь умнее и чуть более деликатно предложишь. А этому — напомнишь, если ещё раз обратится. Может у него просто сейчас денег нет (ну бывает, человек должен кому-то), и потому он так ревностно относится к любой незапланированной трате, даже если реально понты стоит.

Відповісти
Підтримати
anonymus ps 14.05.2021 23:13

В аутсорс надо сперва договорится с клиентом и только потом пилить

Відповісти
Підтримати
Bogdan Shyiak SE or Dev 14.05.2021 23:15
В аутсорс надо сперва договорится с клиентом и только потом пилить

В продукті так само, треба спочатку говорити з продукт овнерами, а потім пиляти :)

Відповісти
Підтримати
anonymus ps
anonymus ps 15.05.2021 08:06

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

Відповісти
Підтримати
Bogdan Shyiak
Bogdan Shyiak SE or Dev 15.05.2021 13:16
Не совсем, я сейчас в продукте, и часто поправляю что меня бесит, все довольны.

У вас логічна помилка: ваш конкретний досвід не можна узагальнити на всю індустрію.
В вашій компанії може бути як «довіра і інтегрованість розробників в продукт менеджмент» так і просто «всрата організація внутрішніх процесів». Ні те ні інше не залежить від типу компанії:
Є купа продуктових компаній, де без апрувного тікета навіть в девелоп код не попадає. Є купа проектів в аутсорсі, де замовник просто дивиться щоб стратегічний напрямок був той що необхидно, а команда може робити все що захоче.

Відповісти
Підтримати
anonymus ps
anonymus ps 15.05.2021 14:57

Из 5 продуктовых контор где работал делал так в 4 и все было ок. Ещё так делал на фрилансе на 3 проектах, но по факту это был парт тайм на удаленьки (даже, клиент это сам дополнительно оплачивал).

Но есть правда в том что мой случай особенный, ввиду того что у меня есть ряд умений, которым не обладает 99% программистов (по факту я не знаю ни одного кто бы ими обладал кроме меня) которые для этого нужны.

Відповісти
Підтримати
Bogdan Shyiak
John Kelly 14.05.2021 22:57
Я не до конца понимаю почему. Тут же win-win, что не так?

Заказчит ожидает что ты в свободное время будешь тоже его фичи делать, а не свои.
Но ты можешь свои, если у тебя тасок нет, скажешь рефакторил типа пока тасок не было.
Или обьясни что ты хочешь улучшить кстомеру, и как это поможет, и если он даст согласие, то потом улучшай уже.
Можешь сказать типа, я это сделаю как будет время, или как основыне таски закончу, тогда кастомер с большей вероятностью согласится.

Відповісти
Підтримати
Bogdan Shyiak SE or Dev 14.05.2021 22:54
Мне сказали, что делать фичу и потом приходить говорить — давайте добавим ее ведь я сделал, не лучшая идея.

Я не до конца понимаю почему. Тут же win-win, что не так?

У чому «він» замовника?
Ви додали фічу, яку треба підтримувати, витрачати на це гроші — це як би перша проблема. Ваша фіча може не співпадати зі стратегією замовника, як результат це може негативно вплинути на базу та паттерни використання системи кінцевими користувачами.
Ще проблема, фіча в продакшені — це не лише код, це і еффорти на тестування і саппорт користувачів в продакшені.

Якби ви запропонували фічу, і відповідальна за продукт людина перевірила, що вона потрібна в продукті — це вже інша історія, це проактивність і «продукт-орієнтованість».

Відповісти
Підтримати
Mykyta Berehulia Senior Software Engineer в EPAM 14.05.2021 23:03

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

Відповісти
Підтримати
Bogdan Shyiak
Bogdan Shyiak SE or Dev 14.05.2021 23:14
Я больше имел ввиду оптимизацию старого функционала, а не добавление нового.

Хто заплатить за тестування? Чому ви вирішили, що ви його оптимізували?

Суть проблеми:
Є план, що має привести до деякого результату. Будь-які відхилення від плану — це ризики і їх треба оцінити і прийняти рішення чи не порушать вони план, а зробити це можна лише маючи певну картину проекту.
У вас на вашій позиції є достаня картина того куди і чому розвивається проект?

Відповісти
Підтримати
Mykyta Berehulia
Mykyta Berehulia Senior Software Engineer в EPAM 14.05.2021 23:37

Да, тут возможен конфликт моих интересов и планов — против интересов и планов заказчика, но интересы могут и совпасть. Решение принимаю не я, но в целом общие векторы движения я же вижу, чтоб сделать предложение:)

Відповісти
Підтримати
Bogdan Shyiak
And riy 14.05.2021 22:47

Смотри, у всех аутсорсных клиентов есть четкое понимание какой функционал они ожидают от подрядчика. Клиент сначала собрал митинг и обсудил это «у себя дома», потом сел с менеджментом Епама и так же четко озвучил свои хотелки.

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

Если ты на прямую участвуешь в развитии продукта, можешь предложить фичу на рассмотрение на этапе планирования.
Вносить «свое» на этапе реализации это не профессионально.

Відповісти
Підтримати
Mykyta Berehulia Senior Software Engineer в EPAM 14.05.2021 22:57

Если развить сравнение со строителями, то я условно — сделал колону и прелагаю заказчику взять ее если она его заинтересовала?

Под непрофессионализмом подразумевается — что я лезу через договоренности свыше и продавливаю то что не согласовали? Я говорил об довольно скромных фичах в рамках проекта в изначальном посте. Хм, в целом суть уловил.

Відповісти
Підтримати
And riy
Артем Перекресний WTF over SSH 18.05.2021 14:04

В серйозних проектах є чітка межа. Отут ми малюємо, плануємо, ескізимо, складаємо списки фіч, технологій та інших рішень, закладаємо певну базу під подальший розвиток і складаємо кошторис. В цей момент проект та його кошторис погоджуються та затверджуються. Вірішили так — і робимо отак. Всі нові ідеї — в список фіч для версії 2.0

І да, це різниця між аджайлом та ватерфолом. Бурдж Халіфа — це ватерфол. Аджайл — це бразильські фавели.

Відповісти
Підтримати
Mykyta Berehulia
Andy Pandy 14.05.2021 22:27

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

Відповісти
Підтримати
Andy Pandy 14.05.2021 22:22

У меня встречный вопрос: а зачем? Ты хочешь потратить свое время, свой ресурс на то, что клиенту не нужно, и сделать это безвозмездно. Выучи новый скилл, прокачай фреймворк, добавь строчку в резюме и уйди с Ерата на +1000. ПРОФИТ.

Відповісти
Підтримати

Підписатись на коментарі

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.