10.02.26

Почему программисты недолюбливают аналитиков и тестировщиков?

Этот текст написан в Сообществе, в нем сохранены авторский стиль и орфография

Nightcall

Страница автора

Вопрос к программистам, аналитикам и в целом к людям, кто в теме IT сферы.

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

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

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

Из реальных примеров, в моей компании нет стандартов названия элементов в коде. Я пытаюсь протолкнуть этот вопрос. Поскольку для бизнеса этот вопрос не существенный, тяжело выбить на это средства. Лично для меня нет никакой разницы называть изображение picture или image. В обоих случаях понятно о чем идет речь. Я пишу в документации picture. Разработчик говорит: "надо image". Да пожалуйста, всегда уважаю желание проявить творческий подход, а не сделать "тупо по доке". Приходит второй разработчик и говорит, что надо picture. Он видит в этом принципиальную разницу. И да, разработчики действительно хотят созвониться по теме и чуть ли не подраться за название. При этом идет обвинение аналитика в этой ситуации с обеих сторон.

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

Почему разработчики так недолюбливают аналитиков? Часто такое же отношение наблюдаю и к тестировщикам.

Дискуссии. Обсуждаем финансовые вопросы и даем советы друг другу

Задать свой вопрос

Nightcall

SammaelТестировщик. С одними быстро находишь общий язык, с другими посложнее, но тут уже от человека зависит. С аналитикой точно так же. А щас будет крик боли. Но сколько бы я ни работала, никогда не видела ТЗ, которое не потребуется много уточнять/сильно дополнять и не разбирать на винтики уже после того как его согласовали. На бумаге одно, в реализации другое, а после тестирования со всеми разборами как оно работает и куда это годится - третье. Бывает куришь с разработчиком как поступить тут или там, а потом приходишь к аналитику чтобы он за него обдуманное нами двумя написал на бумагу, иначе все это канет в Лету. Выматывает. Понятное дело, что делать так неправильно, но пока это все додумает аналитик, уже все сроки кончатся. Может быть так только у нас, а в жизни иначе, но что-то мне подсказывает, что нет.21
SammaelПро пренебрежительное отношение к тестировщикам бывает иногда проскальзывает, но это не словесно, а процессуально. Если ты в целом достаточно скилловый и можешь в аргументы, то вряд ли кто-то скажет, что ты просто кнопки сидишь нажимаешь. Мне кажется, что сейчас неадекватов уже не держат, иначе они всем попьют кровь и снизят темп работы.5
Александр ЕфремовСтранный пост. Аналитик который понятно и чётко всё расписывает и к которому не приходится 100500 раз ходить с уточняющими вопросами или вообще править его постановку и контракты т.к. они кривые, или не тупой тестер который ещё сам умеет в гугл и ИИ и которому не нужно по шагам описывать как например выпустить серты - на вес золота и счастье для разраба. Если вам прямо хамят - соответственно или вы столкнулись с отмороженным (такие тоже есть среди разрабов, хотя редко), но а если это системно происходит, ну чё я могу сказать. Скиньте кусок своей постановки или схемы, оценим.11
NightcallАлександр, скинуть обезличенного нечего. Да и скорее всего получу негатив от ноунейм в интернете, к которому не готова. "Странный пост" задает настрой. Тут скорее цель понять природу критики без конкретики, а не оценить работу.0
NightcallSammael, лично мне совсем без правок написать постановку трудно. Всегда есть этап грумминга, на котором разработчикам презентую решение и вносятся правки. Тестировщики как правило почти не задают вопросов, получают уже достаточно "прожеванный" материал.3
Лукьянов ТимурВы обобщаете личный опыт, на всех. Это не совсем правильно. Да, хамы встречаются везде и среди разработчиков и среди бизнес-аналитиков (по контексту подозреваю, что вы про них). Есть хорошие БА, которые подробно всё опишут, что не знают - уточнят. Есть плохие БА, которые требования опишут на коленке, поверхностно, половину нафантазировав, и есть огромное количество просто нормальных. Вторых иногда хочется обложить трехэтажный даже самому доброжелательному и спокойному разработчику. У разработчиков также, есть хорошие, которые вникают в суть и не против уточнить детали. Есть плохие, которые умеют только, если им требования псевдокодом напишут на русском языке. И это не зависит от опыта работы и квалификации. Вам похоже просто не повезло с командой, если часто встречаются хамы и мелочные товарищи, которым принципиально picture или image. У нас кстати БА пишут по русски, а контракты мы уже сами со смежными разработчиками согласовываем, главное, что бы из постановки БА было понятно, что нужно передать/принять обработать и как это сделать. Поверьте, хороших,да и просто нормальных аналитиков мы в разработке любим и уважаем, а то, что иногда бывает матом ругаемся, так это работа нервная, не принимайте на свой счёт. То же самое касается и тестировщика. Они сейчас уже ручным тестированием почти не занимаются, всё больше автоматизированным. По сути это те же разработчики, только пишут на питоне и цели у них немного отличные от наших.5
NightcallАлександр, Какой-то неоправданный сексизм))) Меня заминусуют, но теперь понятно откуда вопрос как найти девушку))18
NightcallЛукьянов, приятно, что где-то не так и я все-таки обобщаю. Спасибо вам за приятные слова :)3
Дмитрий СоколовТут либо хреновый аналитик, либо хреновый разработчик. Без знакомства выбрать верный вариант не берусь.3
АйтишникДоМозгаКостейДмитрий, не стоит исключать и третий вариант: они оба такие!..13
Eвсeй ИвaновДля объективности надо заслушать вторую сторону.5
ИринаЯ системный аналитик несколько лет, согласна с автором про груминг и черновик тз даже, если аналитик не бывший разраб, то не всегда видишь наилучшее решение, стоит обсудить варианты или вообще описать требования/ проблему бизнесово и отдать разработчикам, им тоже интересно подумать . Нейминг я обычно пишу по русски , разработчики делают как удобно. Придирки бывали и часто если перегорел/устал и лень начинать разбираться или неохота ни в чем разбираться , хочется писать код и все, и токсики конечно . ТЗ бывают разные и периодически читая тз коллег и иногда давние свои понимаешь какая это жесть )) На одном проекте была микро команда и монолит, один бэкендер, у нас задачи просто летали , и разработчик оч любил проект , мы часто сразу после получения задачи созванивались и набрасывали схему как что будет работать, разработчик говорил ок я понял , начинал делать , а я писать тз , это идеальная картина :)) с другой командой после придирок был созвон с техлидом и сениором,обсудили формат тз , выслушали пожелания и стали писать так что всех устраивало, но здесь должна быть сильная заинтересованность разработчиков в том чтобы потратить свое время и улучшить работу команды, разработчики были сами заинтересованы , не все такие конечно .3
АйтишникДоМозгаКостейАвтор, хамы и придурки встречаются везде. В любой профессии. И разработчики - вовсе не исключение. Надеюсь, впрочем, что большинство Ваших коллег-программистов, да и не только программистов, все-таки тактичны и корректны. Но что же делать, чтобы общение с программистами давало меньше поводов для нервотрепки? Наверняка среди программистов, работающих по Вашим ТЗ, найдется 1-2 достаточно грамотных и относящихся к Вам если не с уважением, то хотя бы нейтрально. Попробуйте обсудить свое очередное ТЗ с кем-нибудь из них. Объясните, что хотели бы, чтобы документы, которые Вы создаёте, вызывали бы как можно меньше проблем у всех и попросите указать в них парочку слабых мест. Обсудите с ними свои сомнения. После чего попробуйте в 1-2 проектах ориентироваться на их рекомендации. Если после этого часть Ваших разработчиков будет настаивать на одном варианте, а часть - на противоположном, обсудите корректность и уместность обоих вариантов прежде всего с их тимлмдом. Или даже попробуйте поднять этот вопрос на ретроспективе (если, конечно, они в Вашей компании проводятся и это не некий междусобойчик разработчиков). При этом стоит понимать, что для разработчиков Вы - сотрудник другого подразделения, у Вас другие задачи и другое руководство. Как здесь в комментариях уже отмечали, Вы для них - "смежник". Это не значит, что Ваш труд никогда не будут ценить. Но Вас будут по-настоящему уважать только тогда, когда Ваши ТЗ будут вызывать минимальное количество вопросов. Когда любой из его пунктов Вы сможете грамотно обосновать и донести до любого программиста. (Да, тупые, хамло, саботажнии и просто недовольные ворчуны найдутся всегда. Но обычно таких все же меньшинство). В конце концов, ТЗ обычно пишется для двух участников: для Заказчика работ и для исполнителя, в Вашем случае - программиста. (Ну и тестировщика, само собой). Так напишите его так, чтоб у разработчика, как одного из его основных "читателей", с его реализацией возникло как можно меньше проблем.8
ЕкатеринаЗнаете, может быть, это вам такие личности попадаются, которым лишь бы дое... придраться. Может, самооценку так поднимают, мол, я крутой и опытный, я лучше знаю. Или просто не умеют уступать в мелочах. Кто ж их знает. Постарайтесь не принимать на свой счет) Сейчас меня скорее всего заминусят, но все же поделюсь своим опытом х) Я как разработчик ценю и уважаю и тестеров, и аналитиков. Но вот в моменте, когда тестеры находят самые неожиданные баги в, казалось бы, отполированной таске, прям иногда бесит) Раньше я негативно на это реагировала, потому что воспринимала критику кода как критику лично меня, и потребовалось поработать над собой, чтобы с этим разобраться (да и то неуверенность остается). А со стороны, наверное, казалось, что я недовольна коллегой. Так что негатив может быть вызван личными тараканами, но не все хотят/могут что-то делать с этим11
NightcallЕкатерина, спасибо за ваш комментарий и что поделились опытом2
Nightcall1
NightcallNightcall, поправка, 380к :)3
SammaelNightcall, что ж, везёт вашим тестировщикам!5
Там-тамПо поводу названия картинки напрашивается мысль сходить к руководителю аналитики и руководителю разработчиков. Указать общие трудозатраты (, свои, разработчиков и кто ещё там участвовал, созвоны, переделки, переключения разработчиков-они же снова и снова читали постановку), которые ушли на решение этой проблемы picture. Показать, а если на каждую постановку будет по три подобные проблемы, этот ж угрозы срыва обязательств перед заказчиками. И излишних трат проекта, сильное снижение маржинальности. Пусть либо директивно решения спускают, либо выдают ресурсы на статьи по унификации. Письмом, с указанием причастным, чтобы если что - тыкнуть в письмо. И заставить ответить типа "ознакомился, наличие проблемы подтверждаю". А то скажут "я пропустил, было много задач" Еще ощущение, что какие-то конфликты внутри команды(или внутри отдельного разработчика) вываливают на вас. А придирки на название картинки вызывает у меня мысль о том, что заняться больше нечем. Поэтому я склоняюсь к тому, что там что-то на дне лежит, давно нерешённое, а вы просто кукла для битья. Может их похвалить)) не лестью, не общими словами. А от чистого сердца. Пусть даже какая-то мелочь. Пока идёт процесс поиска в них хорошего, то и внутреннее состояние по этому поводу полегче становится. У меня так работает) но наши люди обычно не умеют положительную обратную связь принимать, особенно те, кто нуждается. Аккуратно надо) Ещё предложила бы изучить категоризацию личностей disc. Не люблю деления людей на ярлыки, но она очень гибкая, направлена на то, чтобы найти подход к тому или иному человеку. В свое время я проходила небольшой тренинг по этой теме, мне руководитель советовал. В итоге помогло получше понять некоторых колючих разработчиков, я их теперь люблю)) колючие вредные милахи🥰6
ОбезьянаИндир, я все понимаю, весна скоро, но тут разжигания ни одна экспертиза не усмотрит.12
Комок нервовИндир, так толсто, что аж тонко)4
Там-тамИндир, а где тут разжигание? Автор пишет про позитивных разработчиков. Про уважение к мнению всех разработчиков (любых) и готовности их учитывать. Более того, стремится продвинуть выполнение задач, которые унифицируют подход, уважит мнение разработчиков, сделает их работу более комфортной и они бы смогли тратить время на код, а не выяснение отношений. В тексте нет призыва к плохому отношению к разработчикам или кому-то ещё. В посте четко прослеживается цель: как найти дороги к этим самым разработчикам и выйти к "друзья, давайте жить дружно".6
Дмитрий СоколовТам-там, > придирки на название картинки вызывает у меня мысль о том, что заняться больше нечем Или там под капотом лежит что-то глубинное: скажем, на сервисе исторически сформировалось «picture», и поддержать следует именно этот вариант, т.к. иначе выйдет зоопарк, но… аналитик болтается между мнениями, как тряпка на ветру, абсолютно не понимая собственную предметную область. Ну, это ведь одинаково в словарике переводится, какая разница, да?! Потому слушать в таких жалобах надо ДВЕ стороны, и очень может быть, что разработчики расскажут, как сами в итоге всегда аналитику пишут. З.Ы. Разумеется, вариант «заняться нечем» я тоже не исключаю.5
Andy Lance'''Почему программисты ненавидят аналитиков и тестировщиков''' Вообще, не думал, что мы можем кого-то ненавидеть. Не знаю,как у Вас, - но где бы я не работал, - всегда были прекрасные отношения и с аналитикой и с QA-нженерами. Бывали тёрки с другими командами, но таки с коллегами из разработки.8
Семён АксёновПрограммисты часто интроверты и перфекционисты, им нужно четкое ТЗ, а не "сделай красиво"2
Семён АксёновТам-там, софт скилы решают, умение договариваться важнее умения писать ТЗ)1
Константин ИвановЕсли аналитики и тестировщики хорошие специалисты, то с ними приятно работать, вот и весь секрет.6
LanelesПрограммист .Net с десятилетним опытом. Я вообще соглашусь, что отечественные коллеги более заносчивы, чем коллеги зарубежные. С конца десятых годов "айтишники" стали некой кастой на Руси из-за того, что их зарплаты были выше чем у других. Зная, как говорят мои коллеги про себя и свои компетенции, могу сказать, что гордыня там зашкаливает, хотя их обучили не на самых лучших в мире технологиях и внедрили с ними не самые удачные производственные практики. Отсюда, например в всей стране нездоровое увлечение Питоном и Го, которые часто не подходят для решения проблем которые стоят перед рабочими коллективами. Одна из моих знакомых руководителей замечает, что они иногда напоминают детей.6
ЖеняЕсли често я не думаю, что программисты именно ненавидят аналитиков и тестировщиков, однако хочу признать, что напряжение присутствует. Причина простая: аналитики получаются де-факто заказчиками во многих организациях, а тестировщики – приёмщиками. Даже если аналитики не встают в позицию заказчика, они всё еще явно или неявно говорят программистам что и как делать, а для многих из них это чувствуется болезненно. Ну а тестировщики соответственно контролируют "что из этого на самом деле сделано". Это напряжение в общем то by design, то есть оно на организационном уровне полезно и необходимо, и когда опытные лидеры строят команду, они не хотят от этого напряжения избавиться, по крайней мере полностью. Другое дело что иногда конструктивное противостояние, которое чувствуется дискомфортно, но толкает всех вперёд превращается в токсичность, изоляцию, переводы стрелок и метание какашек (тех самых, которым место на палках, то есть несущих конструкциях любого проекта). Тогда опытные тимлиды или экзеки вмешиваются. Ну а если опыта нет то всё на самовывозе – как команда сама справится с этим напряжением, так и будет. Может одна из сторон будет терпеть, а может кто-то хлопнет дверью и уйдёт. А может удастся договориться и перевести напряжение из деструктивного в конструктивное – за такое можно и повышение схлопотать.9
NightcallИндир, Пока старательно разжигаете ненависть только вы7
NightcallЖеня, интересная мысль. Лично я иногда испытываю похожее напряжение с PO. Особенно если он допускает какие-то ошибки. В моем кейсе PO как раз выступает в роли заказчика.2
NightcallИндир, во всех своих сообщениях вы пишете о ненависти тем самым разжигая ее :)7
Irina IrisСемён, да именно чёткое и ясное ТЗ.3
Большой КушОбычно в этом виноваты процессы, в которых разработчик часто оказывается крайним3
ДСNightcall, я как ведущий тестировщик (как воспитатель дет сада - между сотрудниками) всегда советую нашим аналитикам писать постановки разрабам как детям 5 лет))) всегда помогает найти упущенное.6
ДССемён, вот соглашусь, мне достаточно спросить таких - а вы не охринели? И все заканчивается и все зайки))1
ДССемён, да толку. Говоришь четко должно быть вот так. По факту - ой мне показалось лучше по другому. Ты нормальный? тз тебе тогда зачем. Ну обсудил бы хоть.4
ДСInside, зарплаты? Может дело в том, что вам как разрабу не хотят больше платить? У ведущего тестера потолок 250-300, обычный тестер 100-120 получает. Аналитик 250 в среднем. Откуда зависть?3
АйтишникДоМозгаКостейДС, оригинальный подход, оригинальный! Но лучше излишняя подробность, чем двусмысленность и недосказанность. Как программист я меньше всего хочу при реализации ТЗ думать, что, как у Зощенко, его автор хотел сказать своим замечательным произведением.4
Stanislav ZЭто не аналитиков они недолюбливают. Они Вас недолюбливают. И вместо того, чтобы выстраивать отношение с коллегами (это сложно и часть процесса) , Вы жалуетесь на них на этом сайте. Контрпродуктивно для Вас и для бизнеса. Лайфхак: когда тебе кажется, что все вокруг плохие, выясни, что с тобой не так.2
КириллSammael, если тебе чет не написали делай как хочешь , то что важно то и написали0
Алексей МонастыренкоЖеня, > аналитики получаются де-факто заказчиками во многих организациях, а тестировщики – приёмщиками – это же прекрасно. Тебе, как программисту, надо работать не с реальным заказчиком, а с переводчиком, который разобрался, что ему надо (тот 99% не в состоянии объяснить, а скорее и не понимает до конца), и не с реальным пользователем, который "я что-то нажал, и всё сломалось", а с человеком, который воспроизведёт баг, максимально упростит путь воспроизведения и толково опишет. Как можно не любить таких людей? Разве что если они из рук вон плохо выполняют свою работу, ну или личный конфликт.4
SammaelКирилл, ага, конечно, а потом начинается - вот тут не так, сям не так, если сценарии реальные начинаешь проходить.1
ЖеняАлексей, ты совершенно прав. Это действительно очень хорошо и прекрасно и именно поэтому вообще появилась такая роль в организациях. Проблема просто в психологии: многие люди неосознанно и незаметно для самих себя сопротивляются, если им кто-то говорит что и как делать, если они не приняли этого человека как более старшую/важную фигуру. Даже если так для всех лучше и даже если на деле всё чисто-красиво-горизонтально. И в случае с автором могут срабатывать и вопросы peer vs peer, и вопросы возраста, и пола. Люди это в 99% случаев не специально делают, "оно само" 😆 Есть еще и рациональные причины, иногда аналитики плохо работают. Иногда организация так устроена что они не нужны, но их зачем-то набрали. Иногда девелоперов дрюкают за ошибки аналитиков. Но вот если все рациональные причины отбросить, то остается то что я выше написал: это напряжение, специально внедрённое в систему, у которого есть важная функция. Это как счас агентов в claude code ты заставляешь ставить работу другим агентам, а потом третьих – перепроверять результат. Так получается намного круче, хотя они там явно страдают, срутся и жгут токены.1
Evgenia SamotokhinaSammael, хорошо когда хотя бы есть более-менее актуальные требования и есть на что опираться. Бывает в задаче только название. Или в теле переписка с клиентом из которой непонятно ровным счётом ничего. Тоже тестировщик.2
SammaelEvgenia, очень соболезную. Бывают моменты, когда сама хожу к заказчику, потому что не ясен ОР в узких кейсах.0
user3211230Мы очень любим аналитиков и тестировщиков, потому что если их нет, то их работу надо делать разработчикам :)2
Дмитрий ПономарёвПо поводу тестировщиков я работал с 2-мя видами. Первый это макаки, которые не понимают, что такое компромисс, работают довольно хаотично, и генерируют мало полезных нахождений багов, т.к. находят много всяких вещей, которые либо незначительные баги, либо не относятся к твоей работе, либо не баги вовсе, либо особенности системы. И понятно дело, что когда тебе спамят каждый раз шумом, то тебя это начнет раздражать. Особенно, когда это самому все приходится разбирать. Второй тип это крутые ребята, даже если они сделают что-то не так, то ты с ними можешь созвонить, поговорить, договориться о каких-то условностях. По поводу СА. СА... СА... В общем-то зачастую мне не понятна их роль в команде. Говорить буду о среднестатистическом СА. Это прокладка между БА и разрабами, которая зачастую не может сделать свою работу хорошо, если ее не контролировать, или не ходить уточнять 100500 вещей. Для верхнеуровевой архитектуры есть архитекторы, для бизнеса есть БА, для менеджмента есть пм. Архитектуру на низком уровне могут проработать тимлиды с разрабами, сформировать контракты могут даже обычные разрабы. В эпоху нейронок это все будет не сложно документировать(хотя для этого лучше иметь отдельного техписа тогда уж). Среднестатистический СА с которым я работал не умеет в OpenAPI и JSONSchema, криво описывает контракты - по хорошему все контракты приходится переделывать, но только пока тебя это в конец не задалбывает. Когда в компании много СА, то они начинают придумывать какие-то свои тупые правила, по которым описывают контракты, зачастую это может не соотноситься с правилами хорошего тона в разработке. В итоге они что-то сродни нейрослопов - вроде и работают, и что-то делают, и это может работать, но по-хорошему все лучше переделать. СА не умеют в стандартизацию - в двух похожих эндпоитанх может вернуться на одна и та же модель данных, но немного различающаяся. СА не понимают тонкости разработки. Человек не понимающий тонкости разработки не может формировать качественные контракты и уж тем более проектировать систему. САшники еще рисуют схемы архитектуры на низком уровне по типу DFD диаграмм, но это может делать и БА, и тимлид, и даже разраб. По этой причине я не люблю СА и не вижу в них смысла2
Дмитрий ПономарёвАлексей, > как программисту, надо работать не с реальным заказчиком, а с переводчиком, который разобрался, что ему надо Для этого есть БА, а не СА2
Sergey BaranovSammael, вопрос в уровне требований. Написать супер детальные требования, которые не надо будет уточнять = написать код. Аналитики обязаны держать достаточный для маневра разработки уровень абстракции с одной стороны, и достаточный для полноценного и не двухсмвсленного восприятия с другой. Одно дело, если ваш аналитик не написал вообще какой то альтернативный поток т.к. про него не подумал, и другое, если альтарнативный поток есть, но он сгруппирован с несколькими другими и резолвися в какую то, допустим, ошибку системы. Если ошибка не должна быть показан пользователю в конечном счёте - ее можно не конкретизировать и дать возможность разрабу просто использовать ошибки из фреймворка. Но все выше описанное показывает, что аналитик сидит на двух стульях - надо и не слишком детально, и не слишком абстрактно. Это требует опыта, и чаще всего все равно потребуются доуточнения на этапе тестирования1