Всем привет. Хочу поделиться оттаявшими после затяжной зимы мыслями и поговорить о наболевшем, а именно про организационную часть нашей инженерной работы - как она влияет на процессы и, в конечном итоге, на продуктивность. Возможно, эта тема в том или ином формате уже кем-то освещалась, и не раз, но я тоже хотел бы высказаться. Когда речь заходит о задачах, у большинства сразу в голове появляется Jira. И это не случайно - в какой-то момент она стала стандартом де-факто. Причем интересно, что Jira смогла продавить даже довольно консервативные компании. До нее в ходу были классические ERP-системы. Как правило, это были тяжелые, перегруженные системы, в которых пытались учесть всё и сразу. Сложные и не самые дружелюбные интерфейсы, медленная работа. С такими системами мне приходилось работать, в том числе и как пользователь. Потом пришла Jira и, по сути, изменила правила игры. Она оказалась достаточно простой и понятной, чтобы ее начали использовать повсеместно. Причем не только в IT -  через нее ведут и финансовые, и административные процессы. Но дальше случился довольно неожиданный разворот по известным причинам. И вот здесь, как мне кажется, мы попали в интересную точку. Вместо того чтобы появилось какое-то новое универсальное решение, каждая компания пошла делать что-то свое. Ну и поскольку компания вкладывает средства в разработку собственного решения, то и заказывает она все, что пожелает. В итоге мы начали возвращаться к тем самым тяжелым системам, от которых когда-то уходили. В эти новые решения начинают запихивать всё подряд: отчеты, реестры, сложные цепочки согласований, кучу дополнительной логики. Из простого таск-менеджера снова получается большая, неповоротливая система, работать с которой не просто, а иногда и не хочется. При этом есть важный момент: от гибких процессов производства никто не отказался. И тут возникает диссонанс. Потому что изначально та же Jira была как раз про это. Она хорошо ложилась на гибкие процессы: бэклог, спринты, оценки, сгорание задач - всё это там было нативно и работало достаточно органично. А сейчас получается, что процессы у нас гибкие, а инструменты - тяжелые и перегруженные. Плюс пропал единый стандарт. Раньше, переходя из команды в команду или из компании в компанию, не нужно было заново учиться работать с инструментом - специалист уже примерно понимал, как всё устроено. Сейчас же каждый раз необходимо тратить время на то, чтобы разобраться, как устроена система, что где заводится, что от чего зависит и куда это потом уезжает. И часто к этому добавляется ещё и страх что-то лишний раз трогать. Потому что одно неловкое действие - и у тебя что-нибудь «не загрузилось», «не выгрузилось» или сломалось где-то в другом месте. В итоге всё это начинает бить по самому важному - по продуктивности. Люди тратят время не на решение задач, а на борьбу с инструментом. И тут есть ещё одна проблема, которая на практике всплывает постоянно. У людей банально нет каких-то базовых вещей. Элементарных. Например, настроить нотификации на новые задачи - почта, мессенджер, неважно. Или какие-то простые автоматизации, которые могли бы снять рутину и упростить жизнь. То есть система при этом может быть перегружена сложной логикой, отчетами и процессами, но при этом в ней не хватает самых простых и полезных вещей, которые реально помогают в работе каждый день. То же самое можно сказать и про TMS (test management system). Их не обошёл процесс «индустриализации» нашей сферы, и болячки всё те же. И, как мне кажется, здесь есть важный момент: инструмент не должен усложнять процесс сильнее, чем это необходимо. Если он начинает мешать - значит, в какой-то точке мы свернули не туда.