АГ
ой, да в старых проектах 70% кода вообще не нужно, а 50% вроде как используется, но не вызывается.
Size: a a a
2020 October 17
АГ
есть средства определения этих вещей, но их тоже надо внедрять, разбиратья.
SP
фича которой не пользуется в лучшем случае лежит мертвым грузом а чаще увеличивает расходы.
SP
добавить аналитику дорого только первый раз когда процесс формируешь, потом это незначительные расходы
АГ
чтобы понять, как сделать новую фичу, ты тратишь времени тем больше, чем больше кода. при этом надо ничего не сломать. желательно не сделать то, что уже сделано. вот на это и уходит львиная доля времени - найти уже готовые решения задачи, и использовать их, а не новые еще одни добавлять.
SP
есть еще несколько прикольный следствий у возможности "мерять вещи" - если вещи можно мерять то можно ставить измеримые цели и как следствие меньше времени тратить на пространные формирования требований. Ставишь цель - люди делают, выкатывают и смотрят метрики. Вместо "запилити ка мне вот эту и ту фичу" ставишь такой цель "надо за месяц увеличить количество регистраций на 10% - как?"
SP
проще приоритизировать, проще решать что нада что не надо, имея возможность выкатывать изменения быстро можно быстро отсечь мертвые идеи
АГ
это больше задача на аналитику, чем на реализацию
АГ
бизнес этим должен заниматься, а не разработка)
SP
это больше задача на аналитику, чем на реализацию
тут как с devops - это вещи которые надо закладывать на момент разработки фичи. Не просто "а как она будет работать" но еще и "а как мы будем знать что этим пользуются" или "а как это дело на проде сопровождать, как узнать что все работает?"
SP
бизнес же все еще фапает на понятие software development lifecycle
АГ
пилить параллельно мониторинг. фичи мониторинга - те же фичи.
SP
а еще пилить тесты) что бы имплементация -> прод -> тестирование)
SP
а не имплементация -> тестирование -> прод -> с богом
SP
интересно сколько миллиардов индустрия просрала фапая на такие картинки
АГ
ну а как еще
АГ
не, просто аналитикам тоже надо что-то делать)
SP
не, просто аналитикам тоже надо что-то делать)
я о том что убираешь "стадии" и садишь всех в одну кроссфункциональную команду
k
в целом этот спор про синьеров не синьеров не столь важен. Есть и другие градации. Мол есть люди которым тяжко перепрыгивать между стэками но они идут вглубь - узкие эксперты. Есть люди которые берутся за все но поскольку возможности ограничены знают все по чуть-чуть. Этого хватает для 80% задач и еще на 20 нужны те узкие специалисты. Есть люди которым хорошо дается управление, есть те кто плохо делигирует. Есть те кто любят впадать в analysis paralysis а есть те кто не особо думают над проблемой и "потом разберемся".
Простые градации типа джун мидл синьер подходят только для градации заработной платы/потенциал для ответственности и то в пределах конкретной организации*. Этого недостаточно что бы понять что человек из себя представляет и какую работу он будет выполнять хорошо. Нужен будет ему контроль внешний или "самоорганизуется как нибудь"
Простые градации типа джун мидл синьер подходят только для градации заработной платы/потенциал для ответственности и то в пределах конкретной организации*. Этого недостаточно что бы понять что человек из себя представляет и какую работу он будет выполнять хорошо. Нужен будет ему контроль внешний или "самоорганизуется как нибудь"
я как раз из категории про analysis paralysis кажется :D