Internally developed software емнип

Web development capitalization. Действительно помогает с налогами, но сам процесс тот ещё геморрой и надо потом это аудиторам доказать. Финансы на такое вообще хотят time tracking в Jira чтобы по каждому разработчику можно было с точностью до часа сказать, какие именно задачи ушли в капитализацию. С таким они естественно идут лесом, поэтому в итоге используем процент рабочих часов в месяц в зависимости от роли

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

Третья сторона - это проектное управление, которое отвечает за бюджет, сроки и качество.

Она должна одёргивать то бизнес (куда вам столько фичей, у нас техдолг выше крыши!), то техническую команду (нам надо вот это завтра кровь из носа, отрефакторите потом).

Собственно, это происходит в хороших треугольниках CEO-CTO-CPO.

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

"3" трудно назвать статистически-значимой выборкой, но во всех трех случаях были такие совпадения:

1. "давайте все перепишем с нуля" не сработало ни разу.

2, всегда (!) находился один человек, "гуру", сильно погруженный в архитектуру, с большим политическим весом, "знающий" как надо, и пищущий говнокод без комментариев. Если чтото надо поменять в серьезном куске - все шли к нему, боялись трогать черный ящик. Маленький королек, пестующий свое маленькое королевствто. Надо его убирать. Как правило занимает начальственную должность и возможно истинная причина почему тебя наняли - это его, наконец, ебнуть.

3. обычно удавалось найти магический костыль, из которого все потом прорастало в нормальную сторону. Например реплика "отстающих" по времени данных, но с нормальной структурой, в нормальной современной бд, куда ходят через другой UI мимо текущих систем и тд. И этот костыль постепенно окружает и пожирает старую систему)

сорри за сумбур, уже засыпаю.

О да, именно так. Но там есть несколько подходов которые у прощают жизнь и в то же время являются defendable перед внешними аудиторами, но я дальше decline to answer

@slavasav почему ты нам не рассказал про https://discoverquickly.com/ ?

у них же вроде софт-пейволл, разве нет ?

Да, все верно. Первый месяц за евро, потом 10 евро / мес

я имел ввиду - софт- значит что чисто на клиенте блокируют, по useragent, а поисковикам отдают полную статью, такие вещи легко обходятся через вполне легитимный bypass paywall или noscript расширение - забираем страницу без javascript

Gotcha

А что такое нежесткие зависимости на уровне процесса? Agile? Но по нему итак сейчас все декларируют работу. Проектировать подсистемы с гибкими входными/входными интерфейсами? Но гибкость опять-таки повышает стоимость реализации

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

Лично мое мнение неэтично

Ага его и упоминал. А насчет этичности - soft paywall заключается в том, что их статья полностью доступна в интернете,весь текст, и они выборочно, на основании useragent, подсовывают реальным людям специальные  “неудобства” а поисковикам - отдают весь контент. Все что делает расширение - это убирает способность сайта отличать вас от бота, аналогичного результата можно добиться просто выключив javascript. Вы ничего не ломаете/воруете вы просто отказываетесь выполнять определенный javascript который вам подсовывает сайт. Для меня это стоит ровно на той же полке как и использовать ad-blocker или включать повышенную защиту от трекинга встроенную в мой браузер. Если вы считаете по-другому - это ваше решение.

обижаешь, поищи в этом чате

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

so true

в моей голове не было в этом уравнении СЕО, сдерживание и противовесы были между СТО и СРО. Наверно это связано с тем, что СРО/СЕО часто отсутствовал как класс или был явно слабее своего С-левел коллеги в тех вопросах, которые затрагивают разработку

А я несколько раз видел как раз наоборот, сильный CPO, но не достаточно уверенный CTO, или вообще нет CTO в компании