О вакансиях, самопозиционировании и жизни программистов

меня заинтересовал единственный вопрос в той вакансии:

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

 

1777
Ваш вопрос нужно задавать не в этой теме, а по указанному телефону.
Stephen
Вообще интересное сообщение. Я серьезно. Не совсем понял про шатл в идеальном случае. Программисты все таки обычно взрослые люди живущие с семьями в своем жилье, а не студенты-интерны. Вообще весь пост про идеал больше подходит к тиражной (коробочной) или заказной разработке. Это конечно основное место приложения программистов, но не единственное. Опять же очень как-то специфично и однобоко насчет пользователей. Групп-лид наверно все таки должен немного больше о них знать, чем просто место на диаграмме.
Еще хочу сказать насчет тестеров. Тестеры как выделенный отдельный народ на внедрении/самопальной разработке бизнес ПО - вредны. Хотите кидайте в меня помидорами, хотите как. А вот такое мое мнение, из личного опыта. Потому как через каждые два клика оказывается что они не понимают что такое они тестируют, зачем и какой результат собственно правильный, а какой неправильный. И никакими подробными описаниями/тех. заданиями это не исправишь, потому как нужно еще какой-то квалификацией обладать, чтоб его понять. А альфа-тестирование еще никто не отменял, так что вполне нормально если тестерами выступают пользователи/консультанты/бизнес(систем)аналитик. Такое вот у меня неуклюжее, супротив всех мэтров и технологий мнение.

---------- Сообщение добавлено 12.05.2010 00:13 ----------

Это уже не работа программиста. Программист должен заниматься разработкой. Если его раз в месяц настойчиво попросили перенести столы в бухгалтерии - это не трагедия. Но если замена картриджей все таки вменена ему в обязанности - это уже эникей.

 

удалено, тема нашлась, вопрос закрыт

 

Тестировщик - это квалификация. Если считается, что программист должен быть умным, а тестировать могут идиоты... Ну тогда да, будет, как описано.

 

Мне вакансия сначала очень не понравилась, но потом сменил мнение.

1) Человек пойдет на изменение оплаты в зависимости от работоспособности.
2) Человеку не нужен работник-сноб. При адекватном руководителе кстати небольшие выходы за ДО для работника не заметны.
3) ЗП вполне адекватная для Мухосранска и подобных городов.

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

 

Да, только если тестировщик квалифицированнее программиста, то он и должен работать не тестировщиком, а бизнес-аналитиком.

Так уж случается что сеньоры не идут в тестеры. Да и ставку им такую никто не предлагает.

 

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

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

 

это риторический вопрос, просто интересно, а там разрешено звонить только реально интересующимся самой вакансией и трудоустройством

 

Вот забил уже писать на форуме на проф темы, но тем не менее отмечусь.
Знаю как минимум одну мега корпорацию у которой при разработке/внедрении внутреннего ПО полностью отказались от тестировщиков. Т.е. в качестве тестеров выступают непосредственно бизнес пользователи. При этом резко улучшились скорость и качество разработки.

ЗЫ: у нас увы пока все не 100% так. По прежнему выпускаются иногда для внутреннего пользования иной раз наполовину "сферические кони в вакууме". Т.е. вроде все правильно, все работает, но ряд очевидных сценариев или не реализованы или правой рукой левое ухо чесать надо. Ну и т.д. Т.е. я как бизнес пользователь был бы рад если бы для внутренних внедрений было бы полностью исключено понятие тестирования не программистом и не конечным пользователем.
Естетственно все это не касается коробочной разработки.

 

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

---------- Сообщение добавлено 12.05.2010 12:27 ----------

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

 

jek, аналогично отмечусь.
Свои тестеры из бизнес-пользователей хороши в том случае, если они заинтересованы во внедрении. Обычно это не так. Особенно это заметно при внедрении каких-ть вертикально-интегрированных решений, преследующих цели не данного конкретного общества, а, к примеру, управляющей компании.
Или хороший пример - типовые ИС (в рамках группы компаний) - в обществе уже есть своя система,скажем, ведения БУ, НУ как правило она интегрирована с оперативным контуром, да еще и с управленческим. Но голова принимает решение о организации ЮЛ, ориентированного на ведение учета всем прочим своим дочкам. Ведение должно быть осуществлено на программном продукте, принадлежащем Исполнителю (т.е. вновь организованному ЮЛ). ЮЛ, естественно, имеет свое понимание о программном продукте на котором ему удобно вести учет - и понеслось. ЮЛ делает свое типовое решение и начинает его внедрять. А Общества на местах - всячески препятствуют.
Тогда весь процесс дружно сотрудниками общества саботируется, и скрытый мотив очень прост - "это ваше внедрение приведет к сокращению времени выполнения моей текущей работы, вследствии чего мне добавят новой. Это раз. Два - это означает изменение моего привычного круга обязанностей."
Качество теста при этом - сам понимаешь, фантастическое, разработчики "огребают" по полной. Это обычный способ провалить внедрение по срокам, а в случае субподряда - то и по деньгам. Поэтому как правило для таких случаев пишут протоколы тестирования и подписывают их с обоих сторон.

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

 

MenBS, Сопротивление есть всегда. Однако делать тесты без бизнес пользователей это как операция без больного. Проект возможно и уложится в сроки и деньги, только вот потом его торжественно помесут на помойку. Сразу после подписания актов. Если цель все-таки внедрение то

это нормальное и более того желаемое состояние проекта.

 

jek,
Мысль первая:
состояние, когда на этапе тестирования разработка начинает "огребать по полной" означает что на этапе обследования и постановки было что то упущено. Либо разработкчики у вас - не ахти. И если вы в таком состоянии выкатили проект на бизнес - то у бизнеса сложится вполне определенное мнение. Хорошо если оно будет таким, что "ребята быстро работают и исправляются", но может быть и другим. В случае с сопротивлением, понятно какое письмо пойдет в вышестоящие инстанции. Бодаться придется порядочно.

Мысль вторая:
в теории, тесты пишутся независимо (постановщиками и бизнесом), а в идеале еще и до разработки ). Но на практике я такого не видел никогда. Отношение заказчика к приемке тестового примера в ТЗ - от неформально отрицательного до формально положительного. Это от слова "положить".

Мысль третья:
бизнес к тестам привлекать нужно в обязательном порядке, а то потом они "отморозятся" от приемки работ, а в случае провала проекта виноват останется разработчик. И виноват он будет во всем.

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

ЗЫ: все, хорош умного из себя строить ) пора умных людей читать...

 

Если он наемный то да!

Бред. Вопрос ? кто будет ответсвенный если например из-за ошибки в ПО при проведении одновремении 5 (причем пяти а не 4 или 6) удаляются все записи из определенной таблицы - программисты или тестеры-пользователи которые они не заметили ?

 

Не понял вообще того что вы написали, что такое проведение 5??, но в любом случае ответственный - тот кто подписал протокол тестирования.

 

из всем известного учебника:

 

я вот с этим категорически не согласен, сам подход не верен, рекомендую ознакомиться с MSF
а вот с Mix-ом по поводу тестирования согласен, и он зря говорит, что его мнение супротив всех

 

Не супротив всех.. Поддерживаю...

 

во.. авторитет высказался - тему можно закрывать..