Возникла в теме http://www.forum-volgograd.ru/showthread.php?t=160517 забавная дискуссия для простой вакансии прогера на # и sql захотелось высказаться, а тему-то и закрыли. так что если вдруг модеры решат что пора открыть -- туда мое сообщение плиз присобачьте программист -- исполнитель. это значит что он автоматизирует те процессы, которые пока не автоматизированы. программист -- нижнее звено. помощников у них не бывает, тестеры -- редкость и не подчиняются, юзеров прогер не любит и боится в идеальном случае вокруг него мир, покрытый прохладным пластиком, металлом, айфонами, айпадами и хорошим кофе, стекла чистые, а энд-юзеров нет вовсе. то есть они есть, но только в виде актеров на диаграмме вариантов использования, безупречно отрисованной умным постановщиком на стеклянной стене, а также доступной в pdf на внутреннем портале команды разработчиков. обед когда захочешь, до кампуса возит шатл-автобус. каждый месяц ровная белая зп, а на праздники и после сдачи этапов -- премия и рост грейда. // написал и понял, что описал свое недлинное бытие в компании интел. // не понтов ради указываю, а показать, что так бывает в случае сферической жопы в вакууме ты один в лице админа, заправщика оргтехники, кладовщика, программиста, постановщика и тестера, а вокруг злые тупые юзеры и с частотой не менее 1 Гц у кого-то перестает печатать принтер. наверняка многие помнят свою первую работу. теперь по сути обсуждаемой темы http://www.forum-volgograd.ru/showthread.php?t=160517 две мысли. буду краток 1. пусть вы работаете программером (электриком, столяром, стоматологом), вас вызывает любой босс, дабы поставить любую задачу, которая требует более чем полдня-дня работы и нетривиальна. в этом случае вы не должны шипеть матом про себя, какой он козел и что жизнь не удалась, а лучше б вы были фрилансером и вообще не видели людей, но спокойно записать все что вам сказали. много сказали -- много записать. вам за это тоже платят. потом эту бумагу (в ит и других отраслях ее принято называть техзаданием) вы показываете боссу и убеждаетесь что он и вы говорите на одном языке. если босс шипит и плюется -- стоит попробовать еще разок, если не получается хронически -- сменить босса идеально -- подписать, но даже словесного "все верно, делай" хватит. затем вы говорите что сделаете это за Х дней, если не будут чаще обычного ломаться принтеры. если вы на сдельщине и задача участвует в расчете зп -- неплохо если и об этом вы с боссом думаете одинаково. тогда триада: задача-сроки-бонус будет сбалансирована и станет опорой хорошего решения задачи и правильной атмосферы в коллективе и тогда все будет проще и так делают все знакомые мне успешные программеры (если, конечно, такой порядок как формализация-исполнение-тестирование-всеобщее удовлетворение не заведен ДО вас) 2. я знаком со стартером темы http://www.forum-volgograd.ru/showthread.php?t=160517 и в общем представляю, что и как делается в указанной организации. вы должны быть нормальным быстрым умным открытым человеком, знающим описанные кунг-фу, готовым решать задачи и помогать людям, при этом не превращаясь в жуткого зануду и без слов типа "не, так неправильно" или "мне за это не платят" при этом топикстартер прекрасно понимает, что залог эффективности в разделении труда и выстроенности процессов, а раз так, то случаи чистки программистом принтера в бухгалтерии -- исключение, когда был занят ответственный за такие задачи товарищ вы будете решать правильные задачи правильным способом. да, на вас не будет пахать десяток тестеров и юзабилити-тестирование проведет не обученный сертифицированный товарищ, а вы и пользователи, но вас зовут работать программистом, а не разнорабочим и топикстартер, как и любой хороший руководитель производственного коллектива, работает не меньше всех, а больше, и голова у него болит о большем числе вопросов, чем у программеров с админами, и главная из этих болей -- как сделать хорошо, чтобы никогда не переделывать и как угадать мейнстрим развития бизнеса, обойдя все коробочные решения в своей нише и заслуженно гордясь своим отделом а это -- правильная цель
меня заинтересовал единственный вопрос в той вакансии: т.е. теоретически возможен вариант, когда работаешь стандартные 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-ом по поводу тестирования согласен, и он зря говорит, что его мнение супротив всех