21.05.2010 17:39, cvetkov пишет: > > Q>Как вообще можно разрабатывать не врубаясь в предметную область?? > легко. нужна хорошая спека
Ты ошибаешься, она тоже часто не нужна.
Здравствуйте, Qwazar, Вы писали:
Q>Здравствуйте, Demotivated, Вы писали:
D>>Девелопер привык смотреть предвзято, смотреть на чужой код со своей колокольни, "я бы сделал по-другому", "что это за говнокод такой", "хочешь сделать что-то хорошо — сделай это сам" и т.п. Неизбежно возникновение отношения в стиле "я начальник — ты дурак"
Q>Имхо программист с опытом перестаёт считать любой чужой код говнокодом. "Я начальник — ты дурак" случается если пм-ом становится неопытный разработчик.
А Вы представьте себя в роли такого ПМ.
Вот, предположим, вас только что назначили манагером на небольшой проект, в подчинении несколько девелоперов и тестеров.
Первым делом кидаешься управлять девелоперами.
Им давно не повышали ЗП, думают больше о том, как побыстрее свалить домой, о предстоящем собеседовании в другой конторе, и тп, энтузиазма ноль.
А тебя наоборот, повысили в должности, существенная прибавка к зарплате, глаза горят от энтузиазма, да и просто опытнее их.
Видишь, что сам можешь сделать и быстрее и качественнее, чем все твои девелоперы вместе взятые.
Начинаешь их подгонять, пытаться заразить энтузиазмом, никакого толку.
Включаешься сам в разработку, берешь самое важное на себя, остальным демонстративно поручаешь самое несложное и рутинное.
В итоге получили старшего разработчика, а роль ПМ-а придется брать на себя кому-то другому, например самому инициативному из тестеров
Здравствуйте, злая и глупая, Вы писали:
ЗИГ>а скажите, вы видели хоть одного такого тестера который бы не кликал по кнопкам? чем же они тогда занимаются?
Ну в общем все верно.
Девелоперы тоже в общем тоже только по кнопкам кликают и мышой по столу елозят.
На каком-то уровне абстракции вообще все едино
Здравствуйте, fdee, Вы писали:
F>Поэтому нельзя программисту поручать работы по тестированию, аналитике и управлению проектом.
Не совсем так. Нельзя поручать тестировать тот функционал, который он делал. Неосознанно пытаешься тестировать только то, что хорошо сделано и обходить плохое.
Я работал в команде, в которой не было тестировщиков вообще. Программисты сами тестировали чужой функионал. Получалось отлично.
По моим наблюдениям все просто. И причина одна.
В некоторых областях знаний просто некуда развиваться кроме как в "начальники".
Применительно к топику это, например, тестирование софта, системная интеграция. Наверное, еще что-то.
Там горизонтальное развитие сильно ограничено, потому приходится расти вверх.
А программист пока всю хрень изучит, системы там, архитектуры постигнет в глубину — уже им тестер из соседнего отдела будет командовать, который уделил время развитию менеджерских навыков.
Т.к. тестерские навыки развиваются по самое немогу за первые год-два работы.
Что такое программер с годом-двумя опыта, надеюсь, понятно.
В смысле, что точно есть еще куда расти
Здравствуйте, oncer, Вы писали:
O>в последнее время начал слышать подобные утверждения. O>в большинстве случаев со стороны самих тестировщиков.
O>т.к. такие утвержедния регулярно слышу но не считаю их верными вообще, ... а также вижу случаИ когда бывшие тестры действительно менеджерят Девелоперов решил организовать так сказать опрос с мнениями почему утвержедние верно или не верно.
O>P.S. O>если не тяжело примите участие в одноименном голосовании. статистика — полезная вещь. O>спасиба.
Здравствуйте, oncer, Вы писали:
O>P.S. O>если не тяжело примите участие в одноименном голосовании. статистика — полезная вещь. O>спасиба.
В буквальном смысле ваш вопрос, по существу, абсурден. Так как вы предлагаете сравнивать инженера по качеству и инженер-разработчика. По каким критериям вы будете их сравнивать? По личным качествам? Так это индивидуально и вовсе не привязано к профессии.
Хотя, если вопрос родился, то я, если позволите, перефразирую его так: "Почему, субъективно, в ПМ берут больше из тестеров нежели из программистов?" Ок, я не буду утруждать себя (к сожалению) и доказывать очевидную разницу между первыми и вторыми, т.е. буквально разницу с институтской скамьи: какие люди идут в первые и во вторые. Но разница колоссальная. Я лишь скажу главное- тестеры имеют мотив и они готовы реализовать свою возможность, это осознанный выбор, а программисты не имеют мотива (ну не спрашивайте почему, ну нравится им проектировать и создавать и не рыпаться) и таким образом не реализуют её, они больше ремесленники.
Конечно, в среднем, я не буду брать лентяев, так вот: инженер-разработчик сильно технически развит, чем инженер по качеству. Это очевидно, иначе бы первый поменялся местом со вторым, и поменял бы их местами тот же ПМ.
И естественно, при прочих равных, допустим, управленческих способностях, лидерских качествах итд у этих двух, логичнее выбрать инженера-разработчика. Потому что у инженер-разработчика шире база. А это определяющий критерий, потому что человек способный решить проблему сильно лучше человека определившего проблему. А если учесть, что по роду деятельность более половины будущих ошибок определяются самим же разработчиком, то выбор вообще очевиден. Однако, хаха, выбор в пользу разработчика редко происходит, дело не только в мотивации (как я заметил выше), но и: уровне английского языка (у тестеров он в среднем выше по роду деятельности);
тестеры меньше загружены (это связанно с особенностью современных жизненных циклов ПО и этапов разработки).
, а мы все знаем, что нехватка времени может приводить к(а) это приводит к (б), затем наступает (в) и к увольнениям, а наоборот, избыток свободного времени, заставляет задуматься о планировании карьеры именно(!) в этой компании
Здравствуйте, oncer, Вы писали:
O>Девелоперу разобраться в деталях Тестерской работы — думаю легко (особенно девелоперу доросшему до высоких порзиций — вообще не проблемма). Верно? Верно.
Ох, не хотел бы я, чтобы вы когда-нибудь тестировали мой проект. Пофиг с какой позиции. Потому что хорошее тестирование — это очень и очень непросто.
O>Крутому Тестеру разобраться в деталях Девелоперской работы — не реально. Верно? верно.
Крутой тестер обязан быть крутым девелопером. Если мы говорим реально о крутом тестере, который может создать систему автоматического тестирования для системы, которая дает предсказуемые результаты, обеспечивает высокое тестовое покрытие, а также недорога в поддержке.
O>Думаю знание технологий у девелоперов гооораздо глубже. соответственно Девелопер Гооораздо лучше может оценить риски "гемора определенного рода". O>Для тестеров все что идет глубже UI — черный ящик. Для девелопера — нет.
Здравствуйте, Qwazar, Вы писали:
R>> Тестировщикам чаще приходится врубаться в предметную область, поэтому им проще получить общую картинку Q>Как вообще можно разрабатывать не врубаясь в предметную область??
Практика показывает, что такое бывает и это нормально. Даже в хорошем проекте можно аккуратно разбить функциональность на четко ограниченные контрактами модули, максимально отвязанные от предметной области.
Так что часто (но не всегда, конечно) с суровой окружающей средой первым сталкивается тестировщик.
Здравствуйте, oncer, Вы писали:
O>в последнее время начал слышать подобные утверждения. O>в большинстве случаев со стороны самих тестировщиков.
O>т.к. такие утвержедния регулярно слышу но не считаю их верными вообще, ... а также вижу случаИ когда бывшие тестры действительно менеджерят Девелоперов решил организовать так сказать опрос с мнениями почему утвержедние верно или не верно.
O>P.S. O>если не тяжело примите участие в одноименном голосовании. статистика — полезная вещь. O>спасиба.
Я бы сказал осторожней. На моей практике из тестировщиков чаще получаются хорошие ПМы, чем из программистов.
Объясню.
Программисты часто страдают "мелочным менеджментом", они переносят на проект свою оаптимичтичность в сроках.
При этом тестировщики хотя и не разбираются в технических деталях, но зато знают цену оценкам девелоперов, более реалистично оценивают проект в целом, лучше распределяют ресурсы, как это ни странно. И, наконец, работа тестировщика, обычно состоит из прохождения тестов раз за разом без устали и жалоб на программистов. Умение стоически воспринимать окружающую действительность очень полезно для менеджеров.
Из програмистов тоже получаются хорошие менеджеры, но чаще программисты запирают себя в башне из слоновой кости предпочитая общатся с компьютером, а не с людьми.
SE>Программисты часто страдают "мелочным менеджментом", они переносят на проект свою оаптимичтичность в сроках.
Программист всегда называет реалистичные сроки, только потом прибегает кто нибудь из sales и говорит — а можите побыстрее, у меня клиент ждать не будет, а что если такую фичу убрать, а что если так сделать, а что если... Заключат контракт, а потом говорят — нам нужна такая и такая фича, мы это в контракте прописали и в конечном итоге все равно, сроки становятся реальными, что изначально называл программист. Так что "оптимистичность" сроков которые выдает программист — это миф.
Возможно девушка пыталась вам сказать что у них в организации на должности тестеров берут людей которые не дотягивают по уровню на программиста. Т.е если его заставить писать он да что-то может и напишет, но это что-то лучше в проект не включать..
Даже в Microsoft насколько мне известно, людей сначала берут тестерами, а потом уже переводят в программисты.. Поправте меня, если я не прав.
C>Дело в том что правильный тестер должен знать спецификации не хуже (а то и лучше разработчика). Разработчику достаточно знать свой кусок, а тестер должен представлять как взаимодействуют между собой разные подсистемы.
Да в этом я с Вами согласен. У нас даже был человек к которому притаскивали поломаные базы и он их чинил, должность у него была разработчик-тестер.
C>То что какие-то тестеры работают плохо ни о чем не говорит. Вот ваши тестеры багов совсем не находят? C>а если находят, то какк-же так получается что значительно более компетентный девелопер их пропустил?
Суть теста — найти баги (если сильно упростить). Любой человек может совершить ошибку, как опытный так и не опытный. Да и кстати баги могут быть разного вида сложности, может это орфографическая ошибка, а может через 10 лет вылет программы из-за того что файл базы привысил размер 4ГБ и т.п. Т.е ошибку в орфографии может найти любой, а насчет переполнения базы может сказать только знающий..
C>Зато вот насчет здравомыслящего человека скажу. в работе разработчика нет ничего такого что "не мог выполнить просто обычный здравомыслящий человек"
А зачем тогда 5 лет учиться в институте? Зачем тогда вообще созданы институты? Раз каждый здравомыслящий человек может заменить разработчика и т.п? Здесь вы в корне не правы, если бы все было так просто, то не кто не требовал бы опыта работы..
На первой работе у Нас также начальник считал,
что любого можно заменить любым, в итоге щас испытавает недостаток кадров.
Здравствуйте, AC1D, Вы писали:
ACD>Суть теста — найти баги (если сильно упростить).
Это если ооочень упростить. Но лучше так не делать Иначе окажется, что где-то 80-90% тестов (в зависимости от глючности системы) не нужна в принципе.
C>>Зато вот насчет здравомыслящего человека скажу. в работе разработчика нет ничего такого что "не мог выполнить просто обычный здравомыслящий человек"
ACD>А зачем тогда 5 лет учиться в институте? Зачем тогда вообще созданы институты? Раз каждый здравомыслящий человек может заменить разработчика и т.п? Здесь вы в корне не правы, если бы все было так просто, то не кто не требовал бы опыта работы..
А вы посмотрите, чему учат по профильным специальностям. В значительной мере там пичкают математикой и прочими теориями, которые на практике потом мало кто применяет. Уже поднимали подобную тему. В итоге, если убрать этот "балласт", то в работе применяется лишь незначительная часть тех знаний, которая дается в ВУЗе и то потом надо по ходу работы изучать новые технологии, фреймворки, библиотеки и прочее, так как решению всех задач в "тепличных" условиях ВУЗ-а не обучишь. И к тому же, как показывают наблюдения, реально эти доли навыков и умений осваивают люди, которые не ограничивались решениями задач для лабораторок и курсовых, но и дополнительно упражнялись в программировании, разрабатывая свои проекты. А таких хорошо, если 5-я часть от группы.
И опять же, если бы те 5 лет обучения позволяли подготовить полноправного специалиста, тоже мало кто бы требовал опыта работы. Но на деле это выглядит иначе.
ACD>На первой работе у Нас также начальник считал, ACD>что любого можно заменить любым, в итоге щас испытавает недостаток кадров.
Не, одно дело, что кем попало менять не получится (а если получится, то ненадолго). Другое дело, как получить требуемые знания. И ничего сверхъестественного в получении этих знаний нет. Ключевой элемент — голова на плечах.
Здравствуйте, Demotivated, Вы писали:
D>Включаешься сам в разработку, берешь самое важное на себя, остальным демонстративно поручаешь самое несложное и рутинное. D>В итоге получили старшего разработчика, а роль ПМ-а придется брать на себя кому-то другому, например самому инициативному из тестеров
Значит ПМ-ом стоит брать ленивых программистов, но с опытом Таких которым лень брать чужую работу на себя.
M>И опять же, если бы те 5 лет обучения позволяли подготовить полноправного специалиста, тоже мало кто бы требовал опыта работы. Но на деле это выглядит иначе.
Вуз для примера, мало кто решается брать человека без опыта работы. Это я все про то что нет нечего сложного.. Сложное есть. И менять просто так не получиться.
M>Не, одно дело, что кем попало менять не получится (а если получится, то ненадолго). Другое дело, как получить требуемые знания. И ничего сверхъестественного в получении этих знаний нет. Ключевой элемент — голова на плечах.
Ну как кем попало, программист программисту рознь, меняли людями по спецальности, один может — другой нет хотя и старается...
Здравствуйте, AC1D, Вы писали:
ACD>Здравствуйте, Marduk, Вы писали:
M>>И опять же, если бы те 5 лет обучения позволяли подготовить полноправного специалиста, тоже мало кто бы требовал опыта работы. Но на деле это выглядит иначе.
ACD>Вуз для примера, мало кто решается брать человека без опыта работы. Это я все про то что нет нечего сложного.. Сложное есть. И менять просто так не получиться.
Получается, что всё упирается в наличие готовых знаний и подтвержденных навыков для некоторой конкретной должности. В этом случае, просто так заменить человека "здесь и сейчас" на кого-то со знаниями в другой предметной области без потерь не получится. Это да.
Так или иначе время уйдет на дообучение + на приобретение навыков в полном объеме для выполнения текущих задач.
Но если есть такая возможность дообучить человека, то ничего сверхъестественного в программировании нет, что бы мешало в нем разобраться на достаточном для выполнения текущих задач уровне. Аналогично и для других областей. Ключевой блок, который может иметь место — необходимость перестраивать мышление. С этим могут быть проблемы.
Здравствуйте, SE, Вы писали:
SE>Здравствуйте, oncer, Вы писали:
O>>в последнее время начал слышать подобные утверждения. O>>в большинстве случаев со стороны самих тестировщиков.
O>>т.к. такие утвержедния регулярно слышу но не считаю их верными вообще, ... а также вижу случаИ когда бывшие тестры действительно менеджерят Девелоперов решил организовать так сказать опрос с мнениями почему утвержедние верно или не верно.
O>>P.S. O>>если не тяжело примите участие в одноименном голосовании. статистика — полезная вещь. O>>спасиба.
SE>Я бы сказал осторожней. На моей практике из тестировщиков чаще получаются хорошие ПМы, чем из программистов. SE>Объясню. SE>Программисты часто страдают "мелочным менеджментом", они переносят на проект свою оаптимичтичность в сроках. SE>При этом тестировщики хотя и не разбираются в технических деталях, но зато знают цену оценкам девелоперов, более реалистично оценивают проект в целом, лучше распределяют ресурсы, как это ни странно. И, наконец, работа тестировщика, обычно состоит из прохождения тестов раз за разом без устали и жалоб на программистов. Умение стоически воспринимать окружающую действительность очень полезно для менеджеров. SE>Из програмистов тоже получаются хорошие менеджеры, но чаще программисты запирают себя в башне из слоновой кости предпочитая общатся с компьютером, а не с людьми.
стереотипы какие-то из серии "все прогеры — казлы". у них жа баги
точно на тех основаниях могу утверждать, что:
1. QA часто забивают на работу, т.к. она скучная и закрывают непроверенные баги
2. QA часто жалуются, что им приходится преоткрывать баги, хотя они просто не понимают, что это уже другой баг и приходится вечно их тыкать носом
3. QA часто не готовы выполнять проверку одних и тех же багов, потому все время бегают и просят чтобы их закрыли намертво
4. QA часто говорят, что не могут проверить многие вещи, т.к. это вне их компетенции, что тут нужно (ах) программирование
5. QA часто не докличешься — сядет такой за компом, все телефоны выключит и айда себе аську тестить
6. QA ... да ладно вам... вот мы дружим с нашими QA — они наше все. если они нашли баги — это супер и честь им и хвала. Хорошо, что это не пошло в продакшн.
не надо тут нам рассказывать. мы работаем вместе и работы у всех хватает.
Это у вас там какие-то программисты недоделанные.
И Qa тоже небось из первых 5 пунктов. Вряд ли они станут менеджерами. Так и будут в одну кнопку тыкать всю жисть.
А наши qa — наше все
И программировать тоже умеют, но не так, как находить ошибки в нем самом.
Бывало, сам закодит, сам ошибку найдет и сам же исправит
Они и менеджерами и хоть куда.
С программистами им конечно сложно конкурировать, но всякое бывает.
Здравствуйте, s.ts, Вы писали:
ST>Это у вас там какие-то программисты недоделанные.
Это типа такое завуалированное оскорбление?
ST>И Qa тоже небось из первых 5 пунктов. Вряд ли они станут менеджерами. Так и будут в одну кнопку тыкать всю жисть.
Такие долго не протянут Не представляю где такие нужны. Но такие попадаются... время жизни у них правда полгода, не больше. Пока не станет понятно, что ничему кроме тыканья одной кнопки они ничему не научатся.
ST>А наши qa — наше все ST>И программировать тоже умеют, но не так, как находить ошибки в нем самом.
Не поверишь...
ST>Бывало, сам закодит, сам ошибку найдет и сам же исправит
Это как? У вас тестировщики код пишут?!
ST>Они и менеджерами и хоть куда.
Ну вот Вы со мной и согласились, что тестировщики "и менеджерами и хоть куда"
ST>С программистами им конечно сложно конкурировать, но всякое бывает.
Программисты нужны на их месте. Ибо они на нем наиболее эффективны.
