В программисты или в тестировщики (идти)? — Хабр Q&A

В программисты или в тестировщики (идти)? — Хабр Q&A Аналитика

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

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

Разбираем первый случай Для начала рассмотрим структуру требования, как такового. Ссылки что такое требование Если коротко, то у нас получается две составляющие требования. Часть которая относится к управлению. И часть которая описывает собственно содержание. Итого мы имеем управленческие атрибуты и описание сути. К управленческим атрибутам относится автор, критичность, сложность и стоимость реализации, сроки реализации и т. д..

Теперь представим что ПМ и аналитик пришли на встречу с заказчиком на каком-то из этапов заключения договора. Им предстоит торговаться по срокам и суммам. У них готов хорошо написанный аналитиком документ. Но при этом пм знаком с ним только поверхностно. И особо в структуризацию и детализацию требования не вникал. Типа – “не царское это дело”… И сталкивается с классической ситуацией: На встрече выясняется, как это бывает практически во всех случаях, что для разработки не хватает либо времени либо денег, а то одновременно и того и другого.

ПМ тут же начинает “жать на все педали” чтобы “продавить документ” и выторговать общую запланированную сумму… Не трудно догадаться, что ждёт наших разработчиков на этом пути… Но тут может вмешаться аналитик с предложением пройтись по документу и определиться, а все ли описанное в документе на самом деле так “необходимо-надобно” заказчику? Очень часто оказывается что Заказчик действительно может пойти на уступки, НО!… не по деньгам, а с реализацией одного или нескольких требований. Таким образом, аналитик становится ведущим звеном в переговорах, а ПМ, на котором вроде бы должна лежать такая обязанность, – оказывается в тени. И, если не делает соответствующих выводов, то очень скоро ПМ-ство может перейти к аналитику. Так часто и вырастают ПМ-ы из аналитиков.

В практике автора был вообще курьёзный случай, когда ПМ, нежелающий работать с требованиями, оказался не в состоянии составить план работ по проекту. Так этот ПМ легко прощал аналитику что “до сих пор нет финальной версии ТЗ”, но того что нет диаграммы Ганта по задачам проекта просить никак не мог. И аналитику приходилось выполнять работу ПМ-а.

Дополнительный анализ:  Что такое психоанализ по Лакану - Афиша Daily

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

Теперь другая ситуация. От заказчика приходит категорическое требование: реализовать “возможность множественного выбора значений из справочников разрабатываемой системы”. ДевЛид и ПМ в шоке: Требование режет на корню простую архитектуру заложенную в основу разрабатываемой и в разы увеличивает бюджет проекта. Ситуацию спасает только переговоры с участием аналитика, в результате которых обнаруживается что множественный выбор нужен всего лишь для формирования логического условия на выборку данных в аналитике. А во всех остальных случаях в реальной работе множественный выбор оказывается даже вредным и совершенно не нужным заказчику. В итоге бюджет увеличивается “на копейки”.

И в этом случае одна из ключевых функций ПМ-а: торговаться с заказчиком по части реализуемых требований, – им теряется и оказывается перехваченной аналитиком. Два три таких случая и ПМ-у можно прощаться со своей должностью.

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

Но по мере развития проекта появляются рабочие варианты системы и ее начинают активно тестировать. И вот тут наш всеобщий любимец, красавец-мачо аналитик – почему-то оказывается в тени у тестера, а то и терпит конфуз от неготовности ответить на его вопросы.

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

Теперь ещё раз вернёмся к структуре требования и рассмотрим его глубже.

Требование – это некое полезное свойство системы, которое должно быть реализовано по ходу разработки.

Задумаемся, насколько точно это определение: Ведь на ранних стадиях проекта и самой системы ещё нет – как можно говорить о ее свойствах? Только в качестве каких-то умозрительных представлений или описаний.

Потому и Википедия даёт более “осторожное” определение: Требования к программному обеспечению — совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации.

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

Дополнительный анализ:  Эксперты Bloomberg спрогнозировали одобрение SEC биткоин-ETF к концу октября | ForkLog

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

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

Здесь как раз и проявляется слабость требований в привычном для аналитика смысле: Системные свойства в описаниях и умозрительных представлениях (и только). В противовес реальным свойствам “живой”, пусть и через пень-колоду, но уже реально работающей системы.

Вот и получается, что аналитик “балуется игрушками”, а тестер – занимается реальным делом с реальными вещами…

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

Кончилось всё тем, что “маститого гуру”, заведующего такими трудами созданного аналитического отдела, – с треском уволили, а сам отдел расформировали по отделам тестирования и сопровождения.

У заинтересовавшегося читателя может возникнуть законный вопрос: Ну, а если коротко, то о чем это и зачем это? Всё очень просто: как правило, когда на проекте ПМ оказывается “слабаком”, а аналитик – “проходимцем”, то их в первую очередь подозревают в недобросовестности. А на самом деле – причина в не-грамотности. Ребята, если вы узнали себя где-то в заметке – пройдите “ликбез” по управлению требованиям, но только настоящий ликбез. И станете незаменимыми для команды killer-members в современной жесточайшей конкуренции за ИТ-проекты.

Автор Юрий Чернявский, Lead Analyst в ReqnDoc

Кто такие тестировщики в ит: как попали в профессию, что делают и сколько зарабатывают

О первых шагах в тестировании. Я занялся тестированием в 2005 году. Попасть в профессию было просто, тем более для студента специальности «Программное обеспечение вычислительной техники и автоматизированных систем».

Устроился в компанию CPS Labs, из которой затем вышла компания iSpring.

Собеседование было простым:

— Здравствуйте. Хочу у вас работать.

— Хорошо. Вот тестовое задание на программиста. А ещё посмотри на наш продукт: опиши, что тебе понравилось и (особенно) не понравилось.

Вечером того же дня я изучил продукт и написал своё мнение. На следующий день звонок:

— Мы тут подумали и решили, что нам нужен тестировщик. Пойдёшь?

— Да!

Дополнительный анализ:  Аналитик данных в Новосибирске с зарплатой 63 000 ₽: как живет, сколько тратит и откладывает

Но такой метод уже не работает. В те времена можно было прийти без особых навыков и учиться «по ходу дела». Сейчас даже к начинающим тестировщикам предъявляются определённые требования. Для начала надо знать как минимум теорию, пройти базовые курсы.

О развитии карьеры и заработке. Я жил в Йошкар-Оле, а в 2009 году решил перебраться в Санкт-Петербург. Но через год вернулся — оказалось, что уровень зарплат тестировщиков в регионах не сильно отличался от зарплат в Санкт-Петербурге.

Сумма «зарплата минус аренда и прочие расходы» оказалась в пользу родного города. С 2021 года я работаю в международной компании, офис которой открылся в Йошкар-Оле. Здесь поле для развития ещё шире: много проектов, коллеги со всего мира. Язык общения, конечно, английский.

Тестирование — точка входа в ИТ? Я не согласен с тем, что тестировщик сегодня — это лёгкая точка входа в ИТ. Отрасль развивается, требования даже к начинающим тестировщикам растут.

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

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

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

Тестирование — это отдельная техническая дисциплина, и контроль качества из процесса разработки никогда никуда не денется, а значит, что и потребность в тестировщиках сохранится.

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

Был момент, когда я ушёл из тестирования в аналитику. Но вернулся обратно — работать тестировщиком мне нравится больше. Хотя, несомненно, из тестировщиков проще перейти в разработчики, аналитики или менеджеры, чем вообще без опыта в ИТ.

О зарплате. Моя зарплата росла плавно на протяжении карьерного пути. Сегодня диапазон довольно широк, на сайтах с вакансиями можно найти вакансии от 15 до 150 тысяч рублей: зависит от города, опыта, знаний и других условий.


Оцените статью
Аналитик-эксперт
Добавить комментарий

Adblock
detector