Как в 2022 году устроиться в IT компанию разработчиком?

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

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

очевидно автор вопросом «почему меня спрашивают» хочет сказать, что отвечать ему неохота и нечего. ЛОЛ.

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

Да, представляете? Оказывается чтобы купить хлеб нужно где-то брать деньги. А чтобы получить деньги - таки надо взять на себя обязательства.

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

Попробуй сказать по-русски, я нифига не понял.

Кредиты - это рабство, причем добровольное, потребительские ясное дело.

Ага, а свобода - это брать чужие деньги и не отдавать. ЛОЛ.

Пусть другие за них работают как рабы ))

Конечно пусть, именно поэтому идеальный РАБотник - это женатый олень с кредитами, такой и овертаймить будет и кофе варить.

офтоп. твой сайт не работает.

Как в 2022 27.08.21 16:31:18

Я смотрю, ты наперёд думаешь. С такими скиллами профитнее будет работать не программистом.

Могу предсказывать будущее, 100$ за час предсказаний.

Это второй этап внедрения жиры - настройка флоу под проект + работа с постановкой задач и требованиям к реализации.

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

Да, представляете? Оказывается чтобы купить хлеб нужно где-то брать деньги. А чтобы получить деньги - таки надо взять на себя обязательства.

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

А чувак которому деньги с неба сыпятся без обязательств - это чувак который работать не умеет

Видимо все-таки умеет, и получше других. Многие бы так хотели )

потому что не работал никогда, и работодателю он на хер не нужен, ему нужна сделанная работа. Работа - это не детский сад, тут чтобы получать деньги, надо что-то уметь. Хотя бы думать.

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

Кредиты - не долги.

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

А если в конкретных цифрах выразить. Например, уменьшить потребление с 4Гб до менее чем 800 Мб? Где-то до или в процессе еще и с отдельной задачей по обоснованию этих цифр

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

Во-вторых, что делать, если потребние памяти снизилось до 750 МБ, а потом выяснилось, что на отдельных компах оно всё еще 830 МБ? Переоткрываем задачу?

В-третьих, любая попытка ставить формальности и палки (закрытые тикеты) во главе угла приводит к тому, что коллектив массово зарабатывает палки за простые проблемы и игнорирует сложные. В том числе те самые, которые «бесконечные».

Jira/Trac/Bugzilla/etc — это прежде всего вспомогательные инструменты коммуникации. Если программист выполнил свои задачи и решил сообщенные ему проблемы — какая разница, что там у него происходит в трекере? Вот если он занимается какой-то задачей, а при этом второй программист независимо занимается той же задачей, дублируя работу — тогда возникают претензии. Та же история с трекерами времени: кому-то по кайфу протереть штаны 8 часов в офисе, ничего при этом не сделав, но получив ЗП как за полный рабочий день.

И самая большая претензия к таким «вспомогательным инструментам» заключается в том, что они слишком мало вещей автоматизируют и слишком много любят мозги при этом. Например, тестер создает тикет по ошибке — какая версия софта для этой ошибки? Успешность воспроизведения ошибки — это больше половины успеха отладки. То есть, по-хорошему должно быть какое-то Integrated Testing Environment, которое сразу записывает ввод/запросы, логи, версию клиента/сервера, и тогда тестер может одним нажатием сообщить о проблеме, опционально добавив описание — а можно и совсем без описания. Я уже не помню, когда мне в последний раз помогали заголовки задачек, потому что слабо знакомый с кишками тестер довольно размыто их описывает.

В случае же бесконечных задач и новых фич нужно смотреть только на общую картину. Грубо говоря, записать реализованные и нереализованные списки сплошным списком с группировкой по модулям, а для его организации примастырить какое-нибудь VCS и смотреть на прогресс реализации фич. Делать это нужно потому, что по мере изменения системы сообщения в задаче становятся бессмысленными. Вроде задачи «нужно кнопку отмены из квадратной сделать круглой» — программист начинает пилить поддержку круглых кнопок, а через две недели выясняется, что никакой кнопки отмены уже нет на том месте, но круглые кнопки по прежнему нужны в других местах. И тогда задача попадает в некое лимбо, где ее невозможно решить, но при этом они решена. Потому «создание задачи» должно происходить в контексте набора фич на момент создания, а «закрытие задачи» должно происходить в контексте набора фич на момент закрытия задачи. Или кто-то зарепортил багу в интенсивно разрабатываемому модуле, а спустя время бага просто не повторяется.

То есть, при таком постоянно изменяющемся контексте операция над задачей (открытие-закрытие) как бы привязана к некоему снимку-состоянию системы, но при этом сама задача в целом, как совокупность открытия, прогресса, и закрытия, ни к какому контексту не привязана. И тогда логично, что сама задача является бессмысленной лишней сущностью, как классы в ООП. Задача должна трансформироваться вместе с трансформацией системы, и именно актуальное состояние задачи волнует команду, хоть иногда и нужно поинтересоваться историей разработки (для чего я и предложил VCS).

Это второй этап внедрения жиры - настройка флоу под проект + работа с постановкой задач и требованиям к реализации

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

Дождаться 2022 и устроиться.

Всем нужны предыдущие проекты и опыт

Нет.

Что указать в резюме, если реально уже 5 лет тупо ни где не работал?

Ничего.

Вроде как крепостное право давно отменили, а до сих пор спрашивают что я делал все это время и почему не работал.

А что ты делал все это время и почему не работал?

Чтобы человеку с головой и характером заработать деньги - совсем необязательно брать на себя «обязательства»

Например как?

Видимо все-таки умеет, и получше других. Многие бы так хотели )

Что-то умеет видимо, но точно не то что нужно работодателю.

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

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

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

Какой то бред. Jira вообще насрать как ты и что реализовал, причем тут статус таска в Jira?

«Уменьшить потребление памяти» — это нечеткая задача, она никогда не будет решена.

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

Если у вас стадо баранов бегает хаотично туда-сюда и никто не знает что, кем и когда будет сделано - причем тут Jira вообще?

Открывай задачу «уменьшить потребление памяти» и херачь туда затраченное время в часах - пусть твой начальник посмотрит на результаты.

Очень многие задачи по созданию новых фич тоже относятся к категории бесконечных

Если тебе поручили реализовать новую фичу X, а ты её реализовываешь бесконечно без какого-либо промежуточного результата который можно оценить - то твое место с метлой на улице

Если программист выполнил свои задачи и решил сообщенные ему проблемы — какая разница, что там у него происходит в трекере?

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

Сферический программист в вакууме никому не нужен.

Справедливости ради, я и сам вне работы пишу очень мало. Мне это всё ещё интересно, но уже как-то лениво. Работы и так по горло хватает.

Более того в моей локации встретить программиста который в свободное от работы время регулярно ПИШЕТ КОД уже удача

Приятно познакомиться.

Инфантильность тут на лицо, не поспоришь, но это ещё не означает, что работать ТС не способен. Не нужно преувеличивать.

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

Открывай задачу «уменьшить потребление памяти» и херачь туда затраченное время в часах - пусть твой начальник посмотрит на результаты

Я полностью согласен с таким подходом, но я отвечал на
Как в 2022 году устроиться в IT компанию разработчиком? (комментарий)
«сделал задачу - смени статус в Jire»

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

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

Так я же не спорю, только половине из этой информации нечего ловить в задачах жиры. Эта инфа должна быть сконцентрирована, то есть, грубо говоря, я пишу тестеру «потести фичанейм1, фичанейм2 в сценарийнейм1, и фичанейм3». Norgat хочет сказать, что я должен сменить статус задачи. Но ведь задача на доработку нужна для меня, тестировщику нужно задача на тестирование. То есть, как бы нужно создать отдельную задачу «протестируй фичанеймы» или «протестируй исправленность спискабагов» — здесь возможна ссылка на задачу для программиста, а возможно и отсутствие онной. Но бинарные статусы и назначения ответственных, свойственными типичным процессам в жире, нифига не налазят на реальную модель взаимодействия. А значит вместо изменении статусов и ответственных нужно создавать тысячи мелких задач при каждой такой передачи информации от человека к человеку, и тогда сотрудники сидят полдня создают новые связанные задачки и сортируют те, которые им прилетели от других людей.

По классике, знакомой мне еще с CRM/ERP, эту проблему решают путем:
Как в 2022 году устроиться в IT компанию разработчиком? (комментарий)
«Это второй этап внедрения жиры - настройка флоу под проект + работа с постановкой задач и требованиям к реализации»

То есть, это не наш софт — отвлекающее от работы говно, нет, это ваши рабочие процессы неправильные и их нужно перерабатывать на правильные, а там уже наш софт станет сам по себе эффективнее работать.

программиста который в свободное от работы время регулярно ПИШЕТ КОД

Что такое свободное время у программиста? Ну ладно там на ЛОРе пол-часа потрындеть, но писать код, это ж уйма времени. Лично я к вечеру уже нишиша не соображаю, какое в жопу писательство?

Ну ладно там на ЛОРе пол-часа потрындеть, но писать код, это ж уйма времени. Лично я к вечеру уже нишиша не соображаю, какое в жопу писательство?

А вот нефик перерабатывать. Тоже таким был, а потом подумал «нафик одной работой жить?».

А что ты делал все это время и почему не работал?

Путешествовал, спал, кушал, трахался.

Всем нужны предыдущие проекты и опыт, а где их взять?

Братюня, так они и нужны потому что негде взять. Ну ты странный вообще. Устраивайся на галеру за миску риса и нарабатывай опыт. А ты думал тебе сразу 300к в наносекунду будут платить за красивые глаза?

Что указать в резюме, если реально уже 5 лет тупо ни где не работал

Ничего не указывай, так и пиши, что джун без опыта, готов вкалывать.

Сейчас изучаю Python, нравится, если что-то не понимаю, на следующий день врубаюсь и иду учить дальше

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

нефик перерабатывать

ЛОЛ, а что когда ты себе пишешь это не работа? Ты либо крестик сними, либо трусы одень.

ЛОЛ, а что когда ты себе пишешь это не работа? Ты либо крестик сними, либо трусы одень

Когда устаю — делаю перерыв. Когда хочется поссать — иду в туалет.

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

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

Пф-ф-ф, а типа я о чем писал?
Как в 2022 году устроиться в IT компанию разработчиком? (комментарий)
«Как правило, такие трекеры работают только в проде, где есть четкие состояния «тикет создан», «ошибка повторилась», «ошибка исправлена»/«не ошибка»/«не будет исправлена никогда». То есть, маленькие четенькие кусочки работы.»

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

Что-то умеет видимо, но точно не то что нужно работодателю. Любой договор - это обязательства. Любая сделка - обязательства. Сдается мне кто-то тупо не знает, о чём говорит.

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

Так ты если ратуешь за то, что не на надо перерабатывать, то 4-5 часов ты пишешь код на работе, а потом идёшь гулять в лесу и лепить поделки из глины. А если ты после этого ещё себе что-то пишешь т.е. пашешь по 8-10 часов в день без учёта перерывов, то нахер так жить. Ну их в жопу такие фан-проекты. Для себя пишут только те, у кого в данный момент нет работы. Ну или конченые ноулайферы.

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

Я понимаю, о чем речь. Ты про рантье и просто про владельцев бизнеса. Как говорил Тёма Лебедев «место бездаря в нашей компании уже занято. Нам нужны только люди. которые что-то умеют».

Однако же, zgen прав по поводу «чувак которому деньги с неба сыпятся без обязательств - это чувак который работать не умеет» — поскольку с обязательствами не всё так просто. Да, это может быть не сидение в офисе, но совсем никому не быть должным (партнерам, родственникам, чиновникам) не получается. Например, ляпнешь что-то не то в СМИ, и на этом твоя «свобода» закончится.

А если ты после этого ещё себе что-то пишешь т.е. пашешь по 8-10 часов в день без учёта перерывов, то нахер так жить. Ну их в жопу такие фан-проекты

Понимаешь в чем прикол... Некоторые люди думают, что если заниматься спортом — то нужно херячить 50 минут бег 10 км/ч. Или сделать уборку — значит до блеска отполировать каждый квадратный сантиметр квартиры. Учиться играть на муз инструменте — значит по два часа каждый день ходить в муз школу/репетитору. А слабо 1-2 часа в день писать что захочется? В гугле, например, на это вполне формально выделяется 20% времени.

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

Упрощает. Большая фича разбивается на небольшие задачи, за большую отвечает один человек, за мелкие — много человек, ну и так далее. То же самое с большими багами. Пример про потребление памяти плохой сам по себе без привязки к инструменту. Хорошая формулировка была бы «устранить утечку памяти» или «исследовать причину чрезмерного потребления памяти (и почему я считаю ее чрезмерной)», по результатам можно создавать следующие задачи.

Жира — это не инструмент прямого управления. По моему опыту она нужна в основном для двух вещей: трекинг и визуализация большой картины. Если сегодня меня переедет автобус, завтра придёт новый человек, который по жире поймёт кучу бизнес-процессов, текущие баги, фичи, роадмап и планирование. Без этого инструмента он полгода будет сидеть 24/7 на совещаниях, выуживая крупицы информации из десятков, а то и сотен людей.

Говоря иначе, тикет в жире — это не «задача» программисту или тестировщику. Это юнит бизнес-процесса.

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

Непонятно кого они набирают в итоге, тиктокеров или интаграммеров?

Хорошая формулировка была бы «устранить утечку памяти» или «исследовать причину чрезмерного потребления памяти (и почему я считаю ее чрезмерной)», по результатам можно создавать следующие задачи

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

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

Хорошая формулировка была бы «устранить утечку памяти» или «исследовать причину чрезмерного потребления памяти (и почему я считаю ее чрезмерной)», по результатам можно создавать следующие задачи

По-твоему программист может отсидеть 15 часов 47 минут ровно и выдать отчет списка проблем и мер, необходимых для устранения? Нет, этот анализ растянется на два месяца, и все эти два месяца будут возникать новые идеи по устранению жора памяти — и вся твоя красивая формальная модель разбивается в дребезги о суровую реальность. По итогу программист все-таки последует твоим указаниям, создаст задачу анализа, по её закрытию создаст новые задачи рекомендаций по устранению проблем — но при этом вспомнит и тебя, и твою мать, и твоего батю, потому что к реальной работе эти формальные отчеты отношения иметь не будут. Конечно, это при условии, что реальная работа выполняется, а не одни отчеты пишутся.

Жира — это не инструмент прямого управления. По моему опыту она нужна в основном для двух вещей: трекинг и визуализация большой картины

Прежде всего я хотел бы заметить, что созданные и отработанные в жире задачи никак не отображают уровень готовности проекта. Я не знаю про твой личный опыт, но я имею очень много примеров, когда докладывается что-то вроде «готовность 90%», «готовность 95%», хотя реальные цифры скорее 40% и 45% — это прямо классика жанра:

«The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.»
— Tom Cargill, Bell Labs

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

Если сегодня меня переедет автобус, завтра придёт новый человек, который по жире поймёт кучу бизнес-процессов, текущие баги, фичи, роадмап и планирование. Без этого инструмента он полгода будет сидеть 24/7 на совещаниях, выуживая крупицы информации из десятков, а то и сотен людей

И про это я уже писал:
Как в 2022 году устроиться в IT компанию разработчиком? (комментарий)

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

Помогает ли в этом жира и не проще ли было реализовать то же самое в блокнотике/вики — это еще очень спорный вопрос.

Да был вроде тут один такой, а может ещё на каком ресурсе не уверен даже что на русскоязычном, но кажется на ЛОР-е всё же, если я не путаю, анкл_боббик или как-то так (если спутал, извини чувак). Косил под Саныча, представлялся руководителем, но от него прямо за версту несло помесью школотрона и солдофона с Шариковым, разумеется никаким руководителем (адекватным) там и не пахло даже, чел элементарные вещи не понимал и писал какие-то свои комплексы и фантазии о том как оно работает. Вот твои комментарии в этой теме почему-то очень его напоминают мне, даже сложно сказать почему...

Говоря иначе, тикет в жире — это не «задача» программисту или тестировщику. Это юнит бизнес-процесса

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

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

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

А слабо 1-2 часа в день писать что захочется

За час можно только начать вникать в задачу и собраться с мыслями.

нужно херячить 50 минут бег 10 км/ч. Или сделать уборку — значит до блеска отполировать каждый квадратный сантиметр квартиры. Учиться играть на муз инструменте — значит по два часа каждый день ходить в муз школу/репетитору

Ска, ЛОЛ я так всё это и делаю. Буквально, бегаю десятку за 50 минут каждый день, намываю квартиру 4 часа каждую субботу и по два часа учусь играть на рояле через день. Я наверное тупой, криворукий бездарь, но иначе я не могу достигнуть результата (который меня устроит).

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

За час можно только начать вникать в задачу и собраться с мыслями

Ну работай над своим проектом раз в три дня.

два часа учусь играть на рояле через день

Каков прогресс? Я вот «к элизе» уже сносно играю, три месяца учусь. А ведь это что-то уровня Grade 5, хотя на самом деле хорошая игра тянет на дипломную — я это понял, когда три дня тренировался играть только три аккорда одного из финальных фрагментов.

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

В индустрии широко известен принцип 80/20 (за 20% усилий достигается 80% результата; более точно это можно интерпретировать так, что каждый следующий квант результата достигается все большими трудозатратами). Это всегда учитывается, и это работает во многих областях. Это также хорошо подходит к задаче исследования потребления памяти.

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

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

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

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

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

ну если есть что возразить разумно и по-существу, то я тоже могу

ты так и не сказал мне, как же так волшебно заработать без обязательств.

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

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

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

А кто-то вами всеми на основе этих данных должен управлять.

То есть, это не наш софт — отвлекающее от работы говно, нет, это ваши рабочие процессы неправильные и их нужно перерабатывать на правильные, а там уже наш софт станет сам по себе эффективнее работать.

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